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Chapter 1. Overview: 
What the Sniffer Does 


You can observe a lot by watching. 
— — Yogi Berra. 


The Sniffer collects, analyzes and interprets data transmitted in a 
local-area network (LAN). It exists in several versions, each 
tailored to the devices and conventions of a particular network, 
such as ARCNET or Ethernet. This manual describes the 
Ethernet version. 


The various versions of the Sniffer provide the same capabilities 
and report them in the same way. However, they are not 
identical. Differences between the various systems of 
transmission require corresponding differences in what the Sniffer 
does. 


When attached to a network in the same way as other stations, 
the Sniffer listens to all transmission between any stations on the 
network. (It is characteristic of a LAN that every message is 
physically present at every station, although ordinarily each 
station ignores all traffic except messages addressed to it.) 


The Sniffer maintains real-time counts of the flow of frames. It 
selects some of the frames it sees and records them for later 
analysis. Its detailed reports include protocol interpreters which 
translate the various levels of code and display them in English, 
from the data-link level on which everything else rests up to the 
session level used by network applications. 


With its detailed records of exactly what transpires during 
network transactions, it is a powerful too! for trouble-shooting and 
tuning a network and for testing and refining high-performance 
network software. 
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The Sniffer Is Self- 
Contained 


Menu-Driven Controls 


Color Monitor 
or LCD Display 


The Sniffer is a fully portable computer and is completely self- 
contained. It comes with its own Ethernet adapter already 
installed, its own hard disk, and its own operating system and 
software ready to run. 


To start using the Sniffer, you need only plug its power cord to a 
suitable outlet and connect it to the network. You may be able to 
plug it directly to an existing transceiver (perhaps temporarily 
replacing the station usually connected there). Alternatively, you 
may need to install an additional transceiver just for the Sniffer. 


Because there is such a variety of possible connectors, the Sniffer 
does not include the cable by which you attach it to the network, 
but this document explains what you’ll need and how you attach 
it. 


The only customizing of the software you’ll probably find desirable 
is to augment the Sniffer’s definition file of station names. The 
Sniffer can then display both the address codes it observes and the 
names by which you refer to the various machines. (You can 
build your name tables as you go along; see “Managing Names 
Used in Displays and Filters” in Chapter 6.) 


An autoexec batch file already installed on the hard disk starts the 
Sniffer software as soon as you turn the machine on. You operate 
the Sniffer from a menu screen. You move the cursor to the 
choices you want, select options by pressing the space bar while 
they’re highlighted, and press Enter or one of the function keys to 
start an action. Whenever a function key is operative, it’s 
highlighted and labeled in the screen display. 


There is no command language, and there are no commands to 
learn. About the only information you supply by typing is the 
name for a file you wish to save or the details of particular 
transmissions you want to look for. 


When you exit from the Sniffer’s software, it returns you to its 
operating system, MS DOS. The Sniffer is then a standard AT- 
class personal computer operating under DOS. A DOS manual is 
included with the Sniffer. 


The Sniffer’s built-in monitor is high-resolution orange plasma 
display with four intensity levels. You can also connect your own 
color monitor or an external LCD display. The Sniffer provides a 
DB-9 jack for an RGBI monitor that supports the IBM color 
graphics monitor (CGA or EGA). You have only to plug in your 
equipment and to select the corresponding option in the Sniffer’s 
initial menu. 
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The Sniffer Is 
a Specialized Station 
on the Network 


Capturing Frames 
from the Network 


The Sniffer “Hears” 
Every Frame 


Capture Filters 
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Like most of the other network devices, the Sniffer is an 
independent computer with its own software and hardware and its 
own network adapter. It does not need (and does not include) a 
copy of the network management software used by ordinary 
stations on the network. 


As far as the other stations on the network are concerned, the 
Sniffer is a passive member. Like any ordinary station on the 
network, it hears the transmissions from all other stations. It 
notes them for analysis but never responds to the other stations or 
acts as receiver for messages that other stations send. It 
originates traffic addressed to other stations only in a test mode 
designed to load the network. Finally, it can emit test pulses to 
look for cable faults. 


Complete analysis of network activity includes two broad phases: 
capture and display. In the first phase, arriving frames are 
captured and stored in a buffer, and the Sniffer performs some 
analysis with real-time displays of network activity. In the second 
phase, frames displayed in a variety of formats for further 
analytic work. 


Ethernet is a bus system. All stations are connected to a common 
bus. Like every other station on the network, the Sniffer hears 
every frame transmitted. 


The Sniffer’s adapter card makes a temporary record of each 
frame and passes it to the Sniffer’s on-board processor for review. 
The processor filters these just-received frames. It records those 
that pass the capture filter you’ve set and records them for later 
analysis and interpretation, and it discards the rest. 


The number of frames reaching the Sniffer’s network adapter is 
potentially so large that it’s essential to select only a subset. The 
Sniffer applies a filter to each newly-arrived frame and discards 
the frames that do not meet its test. Capture filters are of three 
types: 


° Selection by station address: The Sniffer keeps frames 
sent from or received by a particular station or pair of 
stations. 

e Selection by protocol: The Sniffer keeps frames 


containing any of the protocols you specify. 

® Selection by pattern: The Sniffer keeps frames containing 
a specified pattern of data at a particular position in the 
frame. 

(Yor example, a typical filter might admit only messages to or 


from a particular user and a server with which the user is 
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Real-Time Displays of 
Network Traffic 


experiencing a problem and only those frames involving a 
particular protocol.) 


Setting an appropriate filter is your first step in collecting data. 
Often the majority of arriving frames are immediately discarded. 
The frames that your filter admits then pass to a buffer area from 
which you may display or analyze them, send them to storage, or 
discard them. 


While the Sniffer is collecting data, it measures the rate at which 
frames are arriving and gives you a real-time graphic display of 
meters (which show the data-rate) and traffic statistics (which 
show running calculations of network activity). 


Common to all displays is the traffic density bar, the set of traffic 
statistics above the traffic density bar, and an elapsed time 
counter. 


® Traffic density bar. Displays traffic as kilobytes per 
second, as frames per second, or as a percentage of the 
network’s available bandwidth. You can display all three 
measures of traffic density on either a linear or on a 
logarithmic scale. 


e Traffic statistics. Just above the traffic density bar are 
two rows of statistics displayed by the Sniffer. hese 
include counters for the number of good frames seen by the 
Sniffer as well as for defective and lost frames. In addition, 
there are counters for the number of frames seen, and the 
number of kilobytes and frames accepted, by the Sniffer. 
Finally, the percentage of the capture buffer used by the 
Sniffer is continuously updated. 


6 Elapsed time counter. Shows total elapsed time during 
which traffic statistics are accumulated. 


In addition to the features common to all displays, there are 
features which are unique to particular displays and which provide 
alternative perspectives on network activity. Three optional 
displays of network activity are: 


e Individual counts. The display shows either a count of 
frames per second or kilobytes per second for each station 
contributing to network traffic. The display is expanded in 
real-time. As the Sniffer notices traffic involving stations it 
hasn’t seen before, it makes room in the display to include 
them. 


6 Pair counts. The display reports traffic in terms of senders 
and addressees. For each pair of communicating stations, 
the Sniffer updates a counter for frames per second or for 
kilobytes per second. The pair counts display also expands 
in real-time. 
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e Skylines. Shows the real-time display as a moving 
“skyline.” You see two graphs: one shows either the 
number of frames per second, or the number of Kbytes per 
second, being captured within a time interval which you set; 
the other shows the number of active stations, i.e., stations 
that have sent frames in the interval. You can display all 
three measures of traffic density on either linear or on 
logarithmic scales. 


After they’ve been counted, frames that the filter accepts pass to 
the capture buffer. (On the way, they’re examined by the trigger 
detector, described in a moment.) The capture buffer has room for 
a moderate number of frames (thousands of medium-sized 
frames). Frames accumulate in the buffer in the order they are 
received. 


When the capture buffer becomes full, the Sniffer may halt 
capture or may discard older frames to make way for new 
arrivals, as you’ve elected. If you do nothing to retain the frames 
in the capture buffer, the Sniffer automatically discards them; in 
that case, the frames that remain in the buffer are the ones most 
recently received. 


The trigger detector scans the stream of incoming frames. It’s 
located after the capture filter, so that it looks only at frames that 
have passed through the filter but haven’t yet reached the capture 
buffer (Figure 1-1). 


The trigger detector looks for a frame containing a particular 
pattern that you’ve described. When it finds such a frame, it 
signals a trigger event. The trigger event freezes the capture 
buffer so you can examine the trigger frame and the frames that 
precede or follow it. 


When the trigger detector signals a trigger event, capture ceases, 
either immediately or with enough delay to collect some of the 
following frames. Once capture has been halted, you can: 


e Copy the contents of the capture buffer to a file for later 
analysis or display. 


e Browse through various displays of the frames in the 
capture buffer. 


@ Impose a display filter to select which frames are displayed. 
e Select one or more views (ways of displaying a frame). 


8 Print the contents of the buffer, according to the filters and 
views you’ve specified. 
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Specifying the Trigger 
Pattern 


Displaying the 
Frames in the 
Capture Buffer 


Saving the Capture 
Buffer for Later Analysis 


Selecting the Form of 
Display 


A trigger event halts the processing of incoming data. It causes 
the Sniffer to cease capturing frames until you say you’re again 
ready to receive them. 


A trigger pattern is a set of characters at a particular position in a 
frame. You can make the test match either the presence or the 
absence of the pattern. 


For example, if you’re examining complaints of intermittent 
problems with access to a particular file server, you might set up 
a collection filter that accepts only frames to or from that station 
and a trigger that signals when it spots an error return code. 


The frame that matches the trigger pattern is called the trigger 
frame. When it appears in your display of the capture buffer, the 
trigger frame is identified by a letter T beside it. One of the 
actions during display is Jump to trigger. 


When you set up a trigger pattern, you also indicate where in the 
capture buffer you want the trigger frame to appear. That 
determines whether the buffer contains frames that preceded the 
trigger frame, frames that followed it, or some on either side. 


You have many options for displaying the contents of the capture 
buffer, either to the Sniffer’s screen or to a printer. (You can 
direct. printer output either to a locally-attached printer or to a file 
on one of the Sniffer’s disk drives.) 


You can set up a display filter so that frames that don’t interest 
you are omitted from the display (even though they remain in the 
capture buffer). The mechanism for filtering frames from the 
capture buffer is like the mechanism for filtering frames during 
capture. 


From the keyboard, you can select a command that saves the 
contents of the capture buffer to a file. You can save the entire 
capture buffer or just the frames that are selected by your current 
display filter. 


All displays and analyses work with the data in the capture 
buffer. You can display data that has arrived and is still in the 
buffer, or you can load the capture buffer with data you earlier 
saved to a file. 


The display may contain any or all of the following three reports: 


e Summary view. This condensed form abbreviates and 
truncates some of the information from the Hexadecimal 
view and some of the information from the Detail view. It 
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Windows in the Display 


Two-Station Format 


Ethernet Version 


forces each level of interpretation to fit on a single line. The 
display contains one line for each level of protocol in the 
frame. You can elect to show only the highest level; in that 
case, the Summary view has one line per frame. 


e Detail view. Each frame is decoded to show the type of 
frame and the values of its various fields. If you provide a 
file of symbolic names for station addresses, the Detail view 
augments the station names with the symbolic names 
provided in your file of definitions. 


For high-level frames, the interpretation may take several 
levels. The “higher” level interpretation of a frame is more 
deeply nested within it. The various interpretations are 
shown with the “higher” protocol levels (i.e., the ones that 
are more “deeply” embedded) after the lower ones. 


e Hexadecimal view. The entire frame is listed. You can 
elect whether you want character data displayed according 
to ASCII or EBCDIC conventions. 


The Hexadecimal view and the Detail view show data for just one 
frame. The Summary view shows not only the frame you’re now 
examining but a few on either side of it as well to give context. 


Each view you elect appears in a window. The screen may also be 
divided into two, three, four, or six equal-sized windows, 
according to the number of views and viewports you request. 


The window that contains the cursor bar is the active window. 
The Tab key moves the highlight from one window to the next, 
activating the window where it arrives. When a fraine’s display 
won't fit within its window, you can scroll the active window to 
see the information you want. You can also zoom in to the active 
window, temporarily giving it the entire screen until you zoom out 
and restore the other windows. 


Frequently, analysis concerns the flow of commands back and 
forth between a pair of stations. In that situation, it is often 
helpful to elect Two-station format. Frames from one station are 
shown on one side of the screen or paper, frames from the other 
on the other side. (Frames that are not part of the two-way 
interaction are also shown but in the default format.) 
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Higher-level Addresses 


Two Viewports 


Saving and Restoring 
Setups 


The Protocol 
Interpreters 


Besides the address of the station to which a frame is sent and the 
address of the station which sent it (the DLC addresses), frames 
on a network may also contain other, higher-level addresses. 
Certain protocols permit a frame to include within it a message 
written according to a higher-level protocol, and that protocol may 
provide an addressing scheme of its own. An example of this 
would be the situation wherein a frame must pass through a 
gateway. When you set the Address level filter for higher-level 
addresses, your Summary view display of source and destination 
addresses then shows the highest of the levels checked. 


Sometimes it’s important to compare a frame from one part of the 
capture buffer with a frame that arrived earlier or later. You can 
do that by electing Two viewports. The screen is split into left and 
right halves. In each window, you can scroll the two sides 
independently, permitting you to concentrate on one frame on the 
left and another frame on the right. 


Because there’s a rich choice of options concerning what to display 
and how to display it, the Sniffer lets you save a record of the way 
you are filtering and displaying frames, so that you can readily 
restore a custom setup at startup or recall various other setups 
during a work session. 


The Sniffer doesn’t just capture and store frames from the 
network. It also interprets them. When you select the Detail 
view, you get a set of interpretations for each frame, one 
interpretation for each level of protocol that the frame contains. 
The interpreter labels and decodes the standard fields in each 
frame making it easy to see the message conveyed. 


When you select both a Detail view and a Summary view, the 
Sniffer automatically scrolls the Detail view so that the 
interpretation shown there matches the level you’ve highlighted in 
the Summary view. 


If your network transmits frames whose protocol is unknown to 
the Sniffer’s interpreters, it’s possible to augment Network 
General’s interpreters with a custom interpreter of your own. To 
write one, you’ll need detailed familiarity with the protocol with 
the network’s DLC and LLC conventions (Data Link Control and 
Logical Link Control) and the C programming language. 
Specifications for such an interpreter are provided in Appendix C, 
“Extending Sniffer Protocol Interpreters.” 
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Schematic View 
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The traffic generator permits you to load the network with 
background traffic messages sent from your Sniffer. You can 
specify the addressee, the total length of the frame, the number of 
frames, and the interval between frames in milliseconds. You can 
also specify the content of the initial bytes to control how other 
stations will treat the frames the Sniffer generates. 


When generating traffic, the Sniffer is occupied so completely that 
it cannot at the same time perform its other functions. 


From any of the saved capture files, you can regenerate the 
display of meters and traffic statistics just as though the packets 
were arriving from the network in real time. Playback permits 
you to experiment with the display options that are available 
during capture even when you’re not capturing “live” frames. It 
also makes a convenient way to demonstrate a particular sequence 
to your colleagues or to introduce the Sniffer to people who haven’t 
used it. At a tutorial session based on playbacks, you can: 


° Observe the dynamics of capture, including changes in 
traffic density and the accumulation of traffic counts. 


e Experiment with capture filters to weed out extraneous 
frames. 
e Experiment with triggering (that is, freezing the capture 


buffer when a particular trigger pattern is received). 


e Experiment with recording only part of each captured 
frame. 


To run a playback, you don’t have to be connected to the network, 
so you can use it for experiment, training or demonstration even 
when the network is down or when you’re not connected to it. 


Figure 1-1 conceptualizes the Sniffer’s various functions. It’s 
more a cartoon than a formal diagram, but it correctly conveys 
the flow of data in the Sniffer. 
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Figure 1-1: Schematic representation of the Sniffer’s functions 
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At the top, the Sniffer is connected to the network bus on 
which all transmissions are broadcast. The Sniffer’s 
specially-modified network adapter card retains a copy for 
the Sniffer’s analysis. 


The capture filter immediately discards frames that don’t 
pass its address, protocol, and pattern filters. 


During capture, the meters and counters provide real-time 
display of activity of the captured frames. 


The trigger scans the accepted frames for patterns for which 
it has been alerted. 


The capture buffer holds frames captured from the network 
or loaded from a file. Unless capture is halted manually or 
by a trigger, the earlier frames are discarded to make room 
for the new ones as the buffer is filled by arriving frames. 


Display filters select the frames visible on the screen or 
printer display. 


Display options select the number and type of views 
displayed. 


The frame interpreters decode fields in the frame being 
viewed. 


The set of frames in the capture buffer can be saved to a file 
(with or without winnowing by the display filter). 


Setups (display filters, view options, etc.) can also be saved 
tu a file. 


A stored file of definitions helps interpret station names in 
the display. 


The traffic generator transmits frames containing the data 
you’ve specified at the interval you’ve specified. 


The cable tester emits a pulse and times its echo, looking for 
the reflections characteristic of a short or an open cable. 


Connector to the Ethernet bus. 


Chapter 1. Overview: What the Sniffer Does 11 


Ethernet Version 


12 The Sniffer: Operation and Reference Manual 


Ethernet Version 





Chapter 2. The Sniffer at Work 


Live Examples 


* 


This chapter illustrates the way the Sniffer works and shows the 
kinds of things you can do with it. It presents some examples 
taken from real work sessions and describes some of the questions 
you might ask and some of the displays you might see as you use 
the Sniffer to investigate operations on a network. The examples 
that follow present some of the Sniffer’s reports in considerable 
detail, but don’t dwell on the steps that generated them; 
discussions of the Sniffer’s options and controls are in Chapters 4 
and 5. 


Some of the examples reveal design errors, or at least less-than- 
optimal practices, in the software that was managing the 
transmissions at the time these frames were recorded. That, after 
all, is what the Sniffer is for: to isolate and identify problems. As 
you study these examples, you may be tempted to think we made 
them up or deliberately wrote programs with errors so that we 
could show how to spot them. We didn’t do that. The examples 
are not fictitious. They are taken from actual records of network 
sessions using unmodified versions of software in regular use.* 


We are grateful to Stanford University for permission to reproduce frames 
captured during use of the Sniffer to test Ethernet systems there. 
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Example 1: 
Over-Eager 
Acknowledgment 


Replaying the Original 
Capture 


Our first example involves taking a closer look at a routine 
operation: echoing the display to a remote terminal connected 
over the network. As is often the case, detailed inspection shows 
a protocol that works perfectly (in the sense that it produces the 
proper result without error) but includes excess transmissions that 
contribute needlessly to the total load. 


(The examples use Telnet and TCP/IP frames. The frames are 
included in the files TDEMO.ENC and SDEMO.ENC on the Ethernet 
Demo Disk; if you’d like to examine them further, a note at the 
end of this chapter tells you how to load and display that file for 
yourself.) 


The first few frames of the file of captured data reveal routine 
activity in support of two different machines acting as terminals to 
remote hosts. For this example, we illustrale the Sniffer’s 
operation by looking at those routine transmissions. (Later 
portions of the same file reveal a different problem, described as 
Example 2 later in this chapter.) 


When you’re first getting an impression of the frames the Sniffer 
has captured, it’s often useful to start by replaying the original 
capture. To do that, in the Sniffer’s main menu, highlight Capture 
and then move rightward to the field headed From. Initially it 
says From <Ethernet>. Press Return. From the menu that the 
Sniffer then displays, select the name of a capture file to play 
back (instead of live capture from Ethernet). Figure 2-1 shows the 
menu after you’ve selected TDEMO. ENC. 


To start the playback, move the highlight back to Capture, and 
there press Return. 





Figure 2-1. The main menu ready to play back the capture of frames from the file 
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TDEMO.ENC. 


Replaying the captured file shows the meters and counters as they 
were during capture. At completion, you have a count of the 
number of frames seen, tabulated by source-and-destination pairs. 
In the table, you can see the addresses of the machines that sent 
and received frames (Figure 2-2). 





Figure 2-2. Meters and counters based on playback of file TobEMO.ENC 


Addresses Each frame includes within it the address of its source and the 
address of its destination. These addresses often occur at several 
levels. At the data link level, they identify the station that sent 
the current physical transmission and the station that should 
accept it. At higher levels, they may identify the originator of the 
message and its ultimate recipient. When a message is relayed by 
several machines, the originator and the ultimate recipient may be 
quite different from the current frame’s source and destination. 


At the DLC level, the source and destination identify computers 
attached to the same LAN. More precisely, each identifies, not 
just a computer, but a particular network adapter. (When a 
computer has more than one adapter, the distinction becomes 
important.) 


Source and destination are represented by an arbitrary sequence 
of bits, not (in most protocols) by an English word. The Sniffer 
reports a DLC address in hexadecimal, two characters per byte, 
for example 0207010027c0. The format of an address in a higher- 
level protocol is controlled by the interpreter for that protocol. For 
example, for an address in the TCP/IP protocol, the Sniffer repre- 
sents each byte by a decimal value between 0 and 255, with a 
period to separate successive bytes and the whole enclosed in 
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Names for Addresses 


brackets. A four-byte IP address thus appears in the form 
[36.53.0.181). 


During capture (whether live or playback) the Sniffer examines 
only the DLC level, and so the frequency count shows only DLC 
addresses (Figure 2-2). 


To simplify human conversation, programs or computers are often 
assigned English or English-like names. These names may appear 
nowhere in a frame. Since symbolic names make reports much 
easier to read, the Sniffer maintains a name table in which it looks 
up each address it finds and displays the associated name. 


When you start an investigation with the Sniffer, one of the first 
things to do is supply symbolic names for stations that lack them. 
The procedure is described under “Managing Names Used in 
Displays and Filters” in Chapter 6. On the demo diskette, names 
for some of the stations shown in Figure 2-2 are included in the 
file HDEMO.END. The examples that follow assume that the Sniffer 
has added those names to its working name table. They also 
assume that names have been inserted manually for two DLC 
addresses not included in HDEMO.END. Station 02608C036367 is 
here called xr6, and station 0207010027c0 is called Argus. (These 
names are based on the IP names used in transmission from those 
stations.) At the end of this chapter there’s a note on how to insert 
names so that, if you wish, you can reproduce on your own Sniffer 
the displays shown in this Chapter. 


When the Sniffer’s name table includes names for the addresses 
that appear in Figure 2-2, the next time you run Capture you get 
the same tabulation as before but now with symbolic names rather 
than hexadecimal addresses (Figure 2-3). 
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Figure 2-3. Meters and counters, but with symbolic names for the station addresses. 


Summary Display, For a quick survey of the frames in the Sniffer’s capture buffer, 

Unfiltered go directly to Display, leaving the various options at their default 
values. (If you followed the procedure at the end of the chapter 
for adding the two symbolic names, you need to turn off the IP 
address level.) These use no filters, but show all frames in the 
order they arrived. The view is the Summary view, showing only 
the highest level protocol for each frame. ‘The first screen of the 
display is shown in Figure 2-4. 


Figure 2-4, Summary display of the first twenty frames. 
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Selecting a Particular 
Conversation 


The first twenty frames, visible in Figure 2-4, involve Telnet 
transmissions, presumably between a machine acting on behalf of 
a terminal and a machine acting on behalf of a host. Such a 
relationship seems to exist between the stations labeled Kuan and 
Pine C Gateway and between the stations labeled x76 and Argus. 
Commonly, the host responds individually to each of the 
keystrokes from the terminal. A frame from the terminal often 
carries only a single byte of user data, while responses from the 
host are much more varied. 


To get an overview of one such conversation, we set the Sniffer’s 
controls as follows: 


° Address filters: pass only frames transmitted between the 
stations Kuan and Pine C Gateway; 


e Protocol filters: pass only frames containing the Telnet 
protocol; 

e Time: relative to the start of the exchange (in this case, 
frame 1); 

e View: in two-station format (splitting the screen roughly in 


half, so that frames from one station are shown on the left, 
frames from the other on the right). 


The resulting display appears in Figure 2-5. To show more of the 
response, the view has been scrolled to the right (using the right- 
arrow key); the frame numbers at the left are thus temporarily 
invisible. 





Figure 2-5. Telnet frames exchanged between two stations. 
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It appears that the terminal connected through station kuan is 
involved in scrolling. It sends a hex 01, to which the host returns 
Esc-Y# (perhaps to position the cursor on the terminal’s screen). 


Then the terminal sends three transmissions, each of which is hex 
0B (vertical tab). The first of these evokes the reply Esc-1 Esc- 
¥6k8 Esc-Y#, while the last two appear to retype a fragment of a 
C-program (perhaps because the user at the terminal has been 
editing a line previously displayed on the screen). 


The earlier display showed that the frames were exchanged 
between stations whose DLC addresses were identified as Kuan 
and Pine C Gateway. Where were the terminal and host in fact 
located? Switching to the Detail view (one frame at a time) shows 
an interpretation of each protocol level within the frame. At the 
DLC level, this shows the information we already know, together 
with additional details (Figure 2-6). 





Figure 2-6. Detail view of the first frame. 


At the IP level, shown in Figure 2-7, we can see that the frames 
are being forwarded between rt-kuan (acting as terminal) and 
awanee (acting as host). 
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Figure 2-7. Displaying higher-level addresses reveals the source and destination of frame 1. 


Acknowledgments of 
Telnet Transactions 


From the information in the frames themselves, we can’t tell 
where rt-kuan or awanee may be located. (As it happens, rt-kuan 
is a name for an IBM PC/RT that contains the network adapter 
whose name is Kuan. Pine C Gateway is one of several dedicated 
68000’s serving as inter-LAN gateways, while awanee is a VAX 
reachable from Pine C Gateway.) 


The unselected list. of frames (Figure 2-4) showed both Telnet and 
TCP frames. ‘To examine more closely the dialogue between 
terminal and host, we return to a similar display but with filters 
set as follows: 

@ Address level: IP. 


e Address filter: From IP address rt-kuan to any station and 
reverse. 


e Protocol filter: any. 
e View: summary, two stations. 


e Name length: 18 characters (merely to increase the 
horizontal separation of the fields). 


@ Time: relative to frame 1. 
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Figure 2-8. Acknowledgments to Telnet frames, shown in two-station format. 


A striking asymmetry appears in Figure 2-8. For each 
transmission from rt-kuan, the station called awanee sends one 
acknowledgment. For each transmission from awanee, the station 
called rt-kuan sends three acknowledgments. Why? 


In the TCP protocol, an acknowledgment frame includes an 
indication of the point in the sender’s transmission to which the 
acknowledgment applies. At the start of a TCP connection, the 
sender sets a random integer. With each acknowledgment, the 
recipient increases that random start by the number of bytes 
received, accumulated over the various exchanges within a con- 
nection. The fact the the first three acknowledgments from rt- 
kuan all show ACK=2930104833 indicates that rt-kuan has received 
no more data during the interval between them. 


Are the second and third acknowledgments completely redundant? 
To compare them, we set the Sniffer’s display options thus: 


@ View: Turn off Summary, turn on Detail; set Two view- 
ports. 
e Frames selected: 3 and 4. 
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Figure 2-9. Selecting two viewports facilitates comparison of the acknowledgments of frames 
3 and 4, 


Inspection of the two frames shows that they are identical in all 
respects but one: the value of the parameter window. The value of 
Window has changed from 2044 in frame 3 to 2048 in frame 4. By 
transmitting a value for window, the terminal is notifying the host 
of the amount of buffer available to receive data from the host. 
Window has increased by four (perhaps because the terminal 
emulator has acted upon four bytes recently received and removed 
them from the buffer). 
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We can compare frames 4 and 7 in the same way (Figure 2-10). 





Figure 2-10. Similar comparison of frames 4 and 7. 


Questions to Ask 


Example 2: 
A Problem with 
Routing 


Comparison of frames 4 and 7 reveals that although they have 
different sequence numbers, everything else about them is 
identical. Frame 7’s value for ACK is the same as in frame 4, 
indicating that no further bytes have been received. Curiously, 
frame 7 was sent after the arrival of frame 6, but the content of 
frame 6 is not acknowledged until frame 9. 


While the Sniffer can tell you what happened, it can’t tell you 
why. It suggests several questions to raise with the software 
designers: 


6 Why does rt-kuan transmit three times as many 
acknowledgments as awanee? 


® After frame 3 acknowledges receipt of frame 2, rt-kuan 
sends a separate frame to report a change in the window. 
Are separate acknowledgments necessary or desirable? 


e Why is the third acknowledgment sent? Is it simply an 
error? If so, whose? 


Occasionally the network under study seems to have a sudden 
spike of unproductive activity without apparent cause. One such 
burst has been captured in the file To—EMo.eNCc, which was also the 
source for Example 1. The unexpected volley of frames seems to 
start with frame 32, transmitted from a machine whose DLC 
address is here represented symbolically as Frodo. 
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Figure 2-11. Unfiltered list of frames following the name query in frame 32. 


The Request 
that Started It 


In Figure 2-11, time is reported relative to frame 32. In the six- 
tenths of a second that follow frame 32, there occur sixty frames 
in quick succession. They are attempts to answer the query 
raised in frame 32, but none of the answers can be delivered. 


Examining the Detail view of frame 32, we see that the station 
called Frodo transmitted it to the station called Argus. Within the 
frame, there is an IP message that originated with 
ucbrenoir.arpa and is destined to Argus.* The IP message is a 
request for information about a name, probably as part of a mail 
program, here trying to transmit mail from at machine at the 
University of California at Berkeley (UCB) to a destination at 
Stanford. At Stanford, the process called Argus provides 
responses to name inquiries. 


Note that the symbolic name Argus is used here in two senses that are really 
independent. At the DLC level, it represents the station to which the frame is 
going on the current leg of its journey. At the IP level, it represents the name 
of the process that is the ultimate destination. They’ve been given the same 
name because the IP address Argus is in fact on the machine served by the 
DLC address Argus. 


Using the same name in multiple senses may reduce the clutter of names in 
your display. When it’s important to distinguish between DLC and IP 
addresses, it would be better to edit the name table to make the names 
distinct, perhaps calling one DLC-Argus and the other IP-Argus, or perhaps 
using lower case for DLC addresses and capital letters for IP addresses. 
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Source address {128.32.130.4], ucbrenoir.arpa 





Figure 2-12. Detail view, showing the origin and destination of frame 32. 


Paging down in the Detail view, the nature of the request becomes 
evident in the DNS protocol (for “Domain Name Service”). 
Apparently the program running at ucbrenoir.arpa needs to know 
how to route mail addressed to "sail.stanford.edu". 





Figure 2-13. Content of the DNS name query in frame 32. 


In fact the query asks not just for the routing to that name, but 
for all records that mention it. That is indicated by the notation 
(*,255) in the field headed “Question type” (Figure 2-13). 


Chapter 2. The Sniffer at Work 25 


Ethernet Version 


Prompt Reply Frame 33 contains the response to the DNS query of frame 32. It 

to the Query contains an IP message that originated at Argus and is destined to 
ucbrenoir.arpa. In frame 32, the message is going from the 
machine whose DLC address is Argus to the machine whose DLC 
address is Pine C Gateway. (It’s curious, but not necessarily 
wrong, that the message sets out for Berkeley by a different route 
than it arrived.) Figure 2-14 shows part of the Detail view of that 
frame, interpreting the IP level. 


Source address (36.53.0.10], Argus 





igure 2-14, IP level of the frame containing Argus’ reply to the name query. 


In Figure 2-15 you see part of the answer that Argus provided. 
Note that although there was just one question, since the request 
specified all information, the reply contains nine sections of 
answer (indicated at the highlight in Figure 2-15). 
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Figure 2-15. Part of the DNS reply from argus, mentioning that it has nine answers for the 
query that was asked. 


Repeated Frames When we set the display filters to show any frame whose IP 
Carrying the Same source is Argus and whose JP destination is ucbrenoir.arpa, we 
Response find not just one but a screenful of them sent in rapid succession 


(Figure 2-16). 


0.0437 ucbrenoir 





Figure 2-16. A succession of frames, each an attempt to carry the reply from Argus to 
ucbrenoir. 


All those frames contain the same message (the nine parts of 
Argus’ answer to ucbrenoir.arpa). They all have the same ID 
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(visible in Figure 2-16 as DNS R 1D=166). The same message is 
being repeated as various stations on the network attempt to relay 
it to a station that can handle it. 


The succession of attempts to deliver the response peters out with 
frame 92. It dies because the time-to-live parameter reaches 0. 
Argus originally specified a time-to-live of 30. Each machine that 
retransmits the frame reduces its time-to-live by the number of 
seconds since it was last transmitted, but at least 1. By frame 92, 
after 30 retransmissions, time-to-live has reached 0 and the 
message dies (Figure 2-17). 





The Bouncing Frame 


The thirty attempts to transmit the reply from Argus are not 
simply repetitions. The problem becomes clear when, instead of 
the IP address, we ask the Sniffer to show the DLC station 
addresses for those same frames (Figure 2-18). 
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0.133 Pine C..+Frodo DNS _ R_ID=166 STAT=OK NAME=sail.stanford.e 





Figure 2-18. The frame destined for ucbrenoir bounces fruitlessly between Frodo and Argus. 
(Our figure shows more lines than would be visible on the screen at one time. For printing, 
we combined two screens; at the console, you’d see them by scrolling the display.) 


The heart of the matter is that Frodo thinks that the route to 
ucbrenoir.arpa is by way of Pine Cc Gateway, while Pine c 
Gateway thinks the route is by way of Frodo. So the frame 
bounces back and forth between them until its time-to-live reaches 
0. 


As far as ucbrenoir.arpa is concerned, its request to Argus was 
never answered. Can you guess what ucbrenoir.arpa is likely to 
do in a few minutes? 


Protests Filed While Frodo and pine C Gateway have bad information about the 
routing to ucbrenoir, each recognizes that it is not the way and 
attempts to notify the sender that the message is misrouted. Each 
time either of them receives a frame destined for ucbrenoir, it 
sends an ICMP frame to Argus, describing the offending message 
and saying that it should not have been sent that way. Since 
between them they receive 30 such misdirected frames, they 
generate 30 ICMP frames to argus (Figure 2-19). 
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Figure 2-19. Each bounce generates an ICMP frame protesting a misrouting. (The figure 
has extra lines inserted in the same way as Figure 2-18.) 


How Long Should an The machines Frodo and Pine C Gateway both generate “ICMP 
ICMP Redirect Frame Redirect” frames to report that they do not know how to forward 
Live? the reply from argus to ucbrenoir.arpa. Although these are 


standard ICMP frames, comparing them in the Sniffer’s Detail 
view reveals a difference. Placing frame 61 (from pda, via Frodo) 
beside frame 62 (from Pine C Gateway) shows that they assign 
“Time to live” differently (Figure 2-19). 
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Figure 2-20. Comparing time-to-live in ICMP frames sent by two different machines. 


Impact on the Network 


Each of the ICMP frames sent by pda is assigned its own ID 
(visible in Figure 2-20 as the number 17816) and a time-to-live 
equal to that of the misdirected frame it is reporting. 


By contrast, Pine C Gateway assigns no ID (so that field appears 
as 0) and gives time-to-live its maximum value, 255. 


Routinely making time-to-live a maximum is probably imprudent. 
As the fate of the message from Argus illustrates, a misdirected 
message may be continually resent until its time-to-live expires. 
Setting a needlessly high value may merely increase the number 
of repetitions until the message dies. 


The flurry of activity precipitated by misrouting the reply to a 
single request for name service did not last very long but, for a 
while, consumed a significant portion of the LAN’s capacity. To 
examine the impact, we change the time display in the Summary 
view to Network Utilization. That shows the number of bytes 
involved in the selected frames as a percentage of the network 
capacity (at 10 million bits per second), during a time-window 
around each frame (Figure 2-21). The smaller the window, the 
more variable the utilization appears; the impact of a repeated 
transmission is best seen in a window large enough to contain 
several iterations yet smaller than the complete set. 
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Figure 2-21. Menu to select Network Utilization and to select the size of the window around 
each frame. 


As you can see in Figure 2-22, the percentage utilization 
approaches 7% of the total bandwidth. Such a load is quite 
tolerable —perhaps hardly noticed— if the circumstance that 
produces it is confined to a single case. But it would take only a 
few of these occurring together, or occurring repeatedly, to make 
very serious demands on the network. Perhaps more significant, 
such wheel-spinning makes demands on the computers that 
process the frames, as well as on the network itself. 





Figure 2-22. Percentage utilization of the network’s bandwidth for a 100 millisecond 
window around frames related to the request for name service. 
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To estimate the volume of data transmitted in a single such 
incident, while the display filter is set to pass only relevant 
frames, mark the first frame and re-set the time parameter to 
show cumulative bytes since then. As you can see in Figure 2-23, 
the (unsuccessful) request for a single name service required 
almost 12,000 bytes. 





to the request for name service 


Figure 2-23. Bytes transmitted for frames re ate 
accumulated from frame 32. 





Example 3: The third example concerns frames recorded in the file TDEMO. ENC; 
1 the section at the end of this chapter shows how you can load the 

Who Sifts the 

Out goin g Mail? file from your own Sniffer to explore the example further. 


An unfiltered Summary view of the file shows a number of 
requests for name service being transmitted from the machine 
called Backbone B to the machine called Backbone a. They are 
interspersed with some Telnet activity and some name requests 
from other sources (Figure 2-24). 
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Figure 2-24. Unfiltered display reveals a number of name service requests. 


Turning on the Detail view for the first of the series of name 
inquiries (frame 5), and within it scrolling to IP interpretation, 
reveals that the request originates at a station whose IP address 
is [36.54.0.11}] (for which the symbolic name is Lindy) and is 
addressed to a station whose IP address is [36.54.0.12] (for 
which the symbolic name is Forsythe) (Figure 2-25). 


Source address [36.54.0.11], Lindy 


= 
“Use TAB to select windows:::: 





Figure 2-25. Detail view of frame 5, showing part of the IP interpretation, including the 
message’s source and destination. 


Scrolling further in the Detail view shows the DNS interpretation. 
Within it, you can see the address about which Lindy is asking 
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Forsythe (Irigure 2-26). 





Figure 2-26. Detail view of frame 5, showing interpretation of DNS-level message. 


Pattern of Name Queries To review a set of many such requests, we set the Display address 

from “Lindy” filter to pass messages between JP address Lindy and IP address 

to “Forsythe” Forsythe. When Address Level selects a level higher than DLC, 
the Sniffer shows the (interpreted) IP names as the frame’s source 
and destination (Figure 2-27). 
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Figure 2-27. Summary view of DNS queries from Forsythe to Lindy. 


Seeing the sequence of these requests (spanning an interval of 18 
seconds) suggests that a program at Lindy is forwarding its 
accumulated electronic mail. Apparently, for each message, its 
first step is to send a name query. 


It is also apparent that the electronic mail program does not first 
review its set of messages to find the set of unique destinations. 
(We deduce that from the fact that the list of names includes 
duplicates.) 


Nor is it aware that in the assignment of symbolic names for mail 
addresses, capitalization is not significant, so the address for 
score.stanford.edu must be the same as the address for 
Score.Stanford. EDU. 


Nor is it aware that, since Lindy is itself located on the network 
called stanford.ebu, the full name Lindy.Stanford.EDU must refer 
to the same address as the short name Lindy. 


For that matter, it does not seem to be aware that it is Lindy 
when it requests a route for the name Lindy. 


It looks (from this sequence of frames) as though the mail 
program simply sends out a separate DNS name query for each 
item it is asked to deliver with no pre-processing of its list. In 
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effect, this passes to the network a task which the sender could 
very easily carry out locally. For small volumes of mail, or a 
network of very few nodes, the burden may not matter. When 
there are increases in the volume of traffic, or in the complexity of 
the relaying required to answer each query, it will be increasingly 
valuable to reduce the queries to a minimum set by some 
elementary pre-processing. 


The frames used in the foregoing examples are included in files on 
the Sniffer Demo Disk and also in the Sniffer’s directory ENDEMO. 
You can, if you wish, repeat the examples just shown or explore 
them yourself in other ways. To do that, you should proceed as 
follows to load the capture buffer with the file TDEMO. ENC: 


e Start the Sniffer. 


® From the Sniffer’s main menu, move the highlight to Files, 
and then rightward to Data. There press Enter, to indicate 
that you will supply the name of a saved file. 


e When you press Enter, the Sniffer shows you a list of files. 
They’re files in the directory that the Sniffer uses to save 
captured data. However, the example files aren’t in that 
directory. They’re in a separate directory called ENpEmMo. To 
get to that directory: 


> Move the highlight to select the directory labeled .. 
(two dots). There press Enter. That takes you one 
level up, to the Sniffer’s root directory. Now you 
should be able to see ENDEMO. 


> Move the highlight to select ENDEMO, and there press 
Enter. Now you should see the list of capture files 
included with the Ethernet demo. 


> Select rp—EMo.eNc, and there press Enter. You'll briefly 
see a window showing how many frames the Sniffer 
has loaded into the capture buffer. 


@ Display the capture buffer by pressing F3. 


e Resolve unknown names from an external name file, so that 
your displays show symbulic names as well as hexadecimal 
or decimal addresses. During capture, the Sniffer notes the 
DLC address in the frames it captures. It does not note 
higher-level addresses until asked to display them. 
Therefore: 


> Press F6 to get Display Options. 


> Highlight Filters, and within that Address Level. Turn 
on the IP address level. 
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Move the highlight leftward to Manage Names and 
then to Resolve Names, and there press Enter. This 
opens a window in which you can select the file in 
which to lookup names. 


Select the file Hb—EMO.END and press Enter. The Sniffer 
displays a message indicating the number of symbolic 
equivalents it has found for addresses that were 
already in its working name table but previously 
lacked symbolic names. 


The file HDEMO.END contains no symbolic names for two of 
the DLC addresses that appear in the examples. To provide 
names for them manually: 


> 


Move the highlight to Manage Names and then to Edit 
Names, and there press Enter. This opens a window 
in which you can see a list of the addresses the 
Display driver has encountered, together with the 
symbolic name thus far assigned to each. The list is 
sorted in order of the symbolic names. Addresses that 
lack symbolic names are shown first. 


You may now display the data. The Sniffer substitutes the 
symbolic names it found for addresses at the IP level. You can 
duplicate the displays shown in the preceding examples by setting 
the display options as described with each example. 
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Setting Up the Sniffer 


This is a short chapter. There isn’t much to do. 


Remove from the carton the Sniffer, the related items 
packed with it, the packing list, and the license agreement. 


Read the license agreement. If you feel you can’t accept its 
terms, go no further! You have three days to put 
everything back in the box and to return the Sniffer. When 
you connect the Sniffer to a power supply, you signal your 
acceptance of the terms of the license agreement. 


Use the packing list to check that you have everything. 


Fill out the warranty registration card so you can return it 
to Network General. Turn to Appendix H (at the back of 
this manual), and write in the serial number of your Sniffer. 
Appendix H is a list of points to check when you phone for 
help. If you write in the serial number now, you'll have it 
when you need it. 


When you unpack the Sniffer, you will find the following reference 
publications, in addition to the manual you’re now reading: 


TeleSniffer: Operation and Reference Manual. 
T3200 Reference Manual. 

T3200 Portable Companion. 

The First Time... 

MS-DOS Operating System Manual 


MS-DOS Quick Reference 


The Sniffer is a portable computer manufactured for Network 
General by Toshiba America, Inc.; it operates under MS DOS. 
The machine is equipped with: 


12 Mhz 80286-12 Processor. 
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8 640 KB of main memory and 384 KB of expanded/extended 
memory. 


e One 40 MB hard disk. 


e One 720 KB 3.5" internal double-sided, double-density 
diskette drive. 


e 10.25" internal gas plasma display panel. 


e Network adapter for Ethernet, with its own processor and 
buffer RAM. 


e Built-in voltage selection switch for either 115 VAC or 230 
VAC. 


For carrying, the plasma display panel folds down, and the handle 
extends to form a handy grip. A plastic panel at the back of the 
Sniffer’s left side opens to reveal the connectors to its network 
connection. 


The connectors for external video, printer, and modem are found 
in the back of the Sniffer along with the configuration switches, 
the A/B/PRT switch, and the voltage selection switches. The 
Sniffer is shipped with the A/B/PRT switch set to PRT. Use this 
setting for most Sniffer operations and to assure that the correct 
drive is accessed. See the T3200 Reference Manual for more 
information. 


In the center of the right side is the disk insertion slot; you will 
also find dials for controlling the brightness and the contrast of the 
plasma screen. 


The Sniffer is provided with an adapter plate. It permits an 
Ethernet connector intended for a lockpost fastener to be secured 
with the Sniffer’s screw-fasteners. Use of the adapter plate is 
discussed below beginning with the section, “Network Cable,” 
below. 


The Sniffer is supplied with a power cord, fitted with a standard 
three-prong plug for 117V 60 cycles AC. 
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NETWORK 
CONNECTION 
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Figure 3-1. Connections to the Sniffer’s adapter cards. 


In Figure 3-1, you see the network connector jack on the card 
which occupies the full length, upper expansion slot. The panel 
has been removed. Note that the card has two connectors. Use 
only the 15-pin female D-connector to the left. To the right is a 
coaxial connector covered with a red cap. Use only the D- 
connector. There is at present no use for the coaxial connector. 
Do not remove its cap. 


To connect the Sniffer to the network, you will need a cable with a 
15-pin male D-connector to mate with the corresponding jack on 
the Sniffer’s adapter (Figure 3-1). 


At the other end, the cable must connect to a transceiver on your 
Ethernet bus cable. You’ll need whatever cable or connector your 
transceiver requires. You may already have such cables for other 
stations on your network, or you may have to order one. A 
common but not universal arrangement is to have a male 15-pin 
connector on the transceiver. In that case your cable will need 15- 
pin D-connectors at each end, one male and one female. These 
cables do not come in standard lengths; nor is the length critical, 
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provided you don’t exceed 50 meters. Obtain a cable that can 
reach conveniently from the transceiver to the Sniffer. (You'll 
need to know the length of this and other network cables in order 
to interpret information reported by the cable tester.) 


Ethernet cables are commonly secured by a slide on the cable 
connector which attaches to a lockpost on the device. Personal 
computers, including the Sniffer, are generally provided with 
screw posts which secure cables by screwing them down. If your 
cable is designed for lockposts, you will need to install an adapter 
plate on the end of the cable that attaches to the Sniffer in order 
to secure it to the Sniffer’s adapter card. The adapter plate clips 
on to the plug and provides screws by which the plug can be 
secured. The adapter plate is included with the Sniffer. If you 
don’t need it now, set it aside for some future occasion, and skip 
the paragraph that follows. 


To do this, you’ll need a small flat-bladed screwdriver. 


Slide the threaded clips onto both ends of the adapter plate, and 
insert the screws into the clips. In Figure 3-1la, at the top you can 
see one of the clips positioned ready to slide on, and at the bottom 
a clip is in place with the screw inserted. 





Figure 3-1a. Adapter plate ready for attachment to a D-connector 
with lockposts. 


Align the slots in the adapter plate with the indents in the 
lockposts on the transceiver cable. Press the adapter plate until it 
snaps into position on the connector. 
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Plug the connector with its adapter plate to the DB-15 connector 
in the Sniffer’s slot 3. Fasten the screws to the threaded 
receptacles above and below the connector, as shown in Figure 3- 


1b. 
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Figure 3-1b. Connecting a cable with adapter plate to the Sniffer’s 
network adapter card. 


If there is no available transceiver at which you can connect the 
Sniffer to the network, you may have to obtain and install a new 
one. Network General uses the NT100 transceiver manufactured 
by MICOM-Interlan; others may be equally suitable. 


The transceiver is a passive repeater; it acts as the point of 
connection between one station and the network bus. Basically, 
the transceiver attaches a T to the network bus. While other 
transmissions pass straight through, the branch leads through the 
transceiver’s electronics to the cable attached to a station on the 
network. 


Some models of transceiver require you to cut the network bus, 
and connect the severed ends to either side of the transceiver by a 
coaxial N-connector or a BNC connector if the network uses thin 
Ethernet cable. Others, called “vampire taps,” leave the bus 
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intact and make their connection by piercing the cable’s insulation. 
The vampire connection may be easier to install with less risk of 
additional reflection from the connectors. 


The Sniffer provides support for a color monitor. The advantage 
of using color is that the Sniffer’s display routines make use of 
color to highlight options selected or mark parts of the display. 


To operate the color monitor, you connect your monitor’s cable at 
the CRT port at the back of the Sniffer. Next, you set each of the 
ten configuration switches to the right of the CRT’ port according 
to whether you use an EGA- or a CGA-compatible color monitor. 


@ EGA-compatible color monitor: Set switches 1 through 
10 OFF (down). The Sniffer is shipped this way. 


e CGA-compatible color monitor: Set switches 2 through 9 
OFF (down); switches 1 and 10 ON (up). 


To start the Sniffer with the color monitor option, you select the 
External color monitor option before you select Ethernet Sniffer on 
the Sniffer selection menu (Figure 3-2). 


During operation of the color monitor, you will see the CRT light 
glow just below the display panel. 
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The Sniffer does not itself include a device for displaying screens 
to a group or class, but it can be connected to an overhead 
projector such as the Kodak Datashow. Projectors of that type use 
an LCD display, usually with dark letters on a bright background, 
the reverse of the display on a computer monitor. The LCD 
display is unable to show color or to increase its brightness as a 
way of highlighting. In LCD mode, the Sniffer uses reverse video 
to indicate highlighting, rather than the brightness or color 
contrast of the monitor screen. 


Like the color monitor, the cable for an LCD projector also 
connects to the CRT port. Set the configuration switches as you 
would for a CGA-compatible color monitor: switches 2 to 9 OFF; 1 
and 10 ON. Finally, to operate the Sniffer with the LCD option, 
be sure to select External LCD projector on the Sniffer Selection 
Menu (Figure 3-2) before you select Ethernet Sniffer. Note that 
color and LCD are mutually exclusive options. 


Note that only the display on the external projector is visible, so 
any adjustments to that display must be accomplished with the 
projector. 


The Sniffer’s software is already installed on its hard disk. No 
diskettes are supplied with the Sniffer.* 


Plug it in. Turn it on. (If you’re using a separate color monitor, 
you may need to turn that on, too.) 


The Sniffer’s selection menu comes up at once. (It’s described in 
more detail later in the chapter.) From there you indicate whether 
you’re using an external color or LCD display and start the 
Sniffer. 


When the Sniffer starts, it shows you an initialization message 
and then takes you to the Sniffer’s main menu. That’s the place 
from which you start each of the Sniffer’s principal activities and 
to which you eventually return when you’ve finished. The last 
part of this chapter concerns the main menu and its conventions. 


There are DOS diskettes packed with the accompanying user documentation. 
However, since DOS is already installed on the hard disk, there’s nothing you 
need do with the diskettes but save them for some future emergency. 
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Work with the Sniffer falls into two broad areas, each of which 
has a chapter devoted to it: 


® Chapter 4. “Capturing Frames, Generating Traffic, and 
Testing the Cable.” 


8 Chapter 5. “Displaying and Analyzing the Captured Data.” 


When you’re setting up the Sniffer for the first time, there are a 
few preliminaries that you really ought to note first before you 
capture or analyze data: 


e Make a backup copy of the software, as a protection against 
the possibility that the pre-installed version on the hard disk 
is somehow damaged or lost. It’s highly desireable to 
safeguard yourself against some possible disasters by 
preparing in advance a few diskettes. Therefore, you 
should: 


> Back up everything on the hard disk to diskettes (see 
“Backing Up the Contents of the Hard Disk”). 


> Be prepared to periodically back up capture files as 
you accumulate them (or any other files) on the hard 
disk. 

> When you find you’ve lost some needed files, restore 


them from the diskettes. 


To back up the entire hard disk, proceed as follows: 


e Turn on the Sniffer. It starts its selection menu 
automatically. Select Return to DOS. That brings you to 
the DOS prompt c:\>. 


® To make a complete backup of everything, type the 
following DOS command: 


BACKUP C:\*.* A: /S 


The parameter /s tells DOS to include all files in subdirectories as 
well. 


It takes several diskettes to backup everything originally supplied 
with the Sniffer. The exact number will vary. If you have saved 
setup or capture files, they take space, too. 
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As it goes along, BACKUP prompts you for each diskette it needs 
until the entire job is finished. (It may split a file so that it starts 
on one diskette and concludes on another.) BACKUP asks you to 
insert a diskette that is already formatted. Sadly, it won’t let you 
format them as needed as it proceeds. So it’s important to have 
enough formatted diskettes on hand before you start backing up. 


The first time you run Backup, it’s probably wise to back up 
everything. Later, you can backup just files that have been added 
or have changed since the last backup (by using the parameter /m 
(for “modified”). To limit a backup to a particular directory (for 
example, CAPTURE, which contains files you’ve saved from the 
capture buffer), the command is: 


BACKUP C:\CAPTURE\*.* A: 


You should consult the MS DOS manual for further details on the 
BACKUP command. 


Notice that the files created by BACKUP are not readable or 
executable in the usual way. Each contains within it the name 
that the file had before it was backed up, together with the 
complete path to the directory in which it was located. The 
backup version can be restored only by the RESTORE command and 
only as a file having that name in that-directory. 


Provided the hard disk is functioning and has DOS installed on it, 
proceed as follows: 


e Exit to DOS (as described above). 
e Type a command such as the following: 
restore a: c:\*.* /s 


Here, as with Backup, the parameter /s indicates that you 
want files in subdirectories too. 


As the MS DOS manual explains, you can also elect to 
backup only files in a particular directory, files newer than a 
date you give or files whose hard-disk versions have 
changed since you did the date of the backup. 


In the event that you can’t run DOS on the hard disk (for 
example, because you’ve reformatted it without including the 
system files), boot the Sniffer from the MS DOS diskette supplied 
with the Sniffer. Then type the RESTORE command in the same 
way as shown above. 
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The Sniffer’s Menus 


When you start the Sniffer, it first displays its Sniffer selection 
menu (Figure 3-2). No matter what you'll be doing with the 
Sniffer, this is where you normally start. You always terminate 
and work with the Sniffer by returning to the selection menu and 
by selecting the option Return to DOS or System shutdown. 





Selection menu options 


One of the entries in the selection menu is highlighted. Using the 
arrow keys, move the highlight to the option you want, and there 
press Enter. 


The options on the left side of the menu include the version of the 
Sniffer installed on your machine, TeleSniffer, and Sniffer 
demonstrations. 


8 Version of the Sniffer. To start your Ethernet version of 
the Sniffer, move the highlight to Ethernet Sniffer, and press 
Enter. 


e TeleSniffer. Software which allows you to operate the 
Sniffer remotely from an IBM-compatible personal 
computer. 


One way to start TeleSniffer is to highlight the TeleSniffer 
option on the Sniffer selection menu and to press Enter. You 
then see the TeleSniffer selection menu. Complete 
instructions for using TeleSniffer are available in 
TeleSniffer: Operation and Reference Manual. 


@ Demonstrations. Ali demos for each version of the Sniffer 
on your particular machine are included under one menu 
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item. To start a Sniffer demo, select Demonstration first, 
and then select the demo you want. 


The options at top right permit you to adjust the display screen for 
the type of monitor you’re using. After you select one of them, 
press Enter. Your selection becomes effective at once. The menu 
remains visible, waiting for you to select an action. 


The two options at lower right are exits. When you select Return 
to DOS, you leave the menus and return to the DOS prompt. 


From DOS, you can do whatever you want. The Sniffer is now 


‘behaving as a standard AT-class personal computer. You can 


return to the Sniffer’s selection menu by typing 
menu 


Alternatively, you start the Sniffer directly (without benefit of the 
selection menu) by typing 


ENSTART 


System shutdown parks the heads of the hard disk. It is essential 
to do this before moving the machine (and prudent whenever you 
turn the machine off, even if you don’t plan to move it). Once 
you’ve selected System shutdown, turn off the power. You can’t do 
anything else until you next turn power on. 


The Sniffer is controlled from a series of menus linked together in 
a tree structure. The main menu is at the root of the tree. 
Regardless of where you are in the tree, your current position 
appears highlighted at the center row of the center window. You 
traverse the tree by using the arrow keys. Each press of an 
arrow takes you to the next node in the direction of the arrow. 


When you start the Sniffer, the first thing it does is display the 
main menu (Figure 3-3). 
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Figure 3-3. The first panel of the Sniffer’s main menu. 


Each menu screen consists of three panels arranged from left to 
right. The center row of the center panel is highlighted. It shows 
where in the tree you are now. 


The highlight is always at the center of the center panel. It’s like 
a movable viewport through which you look at the tree. As you 
press one of the four arrows, the viewport moves over the tree. 
Stating the same thing from an opposite perspective, pressing an 
arrow causes the tree to move under the viewport and brings a 
different part of the tree into view. 


At the bottom of the screen, there’s a one-line description of the 
highlighted action. (You can obtain a more detailed description by 
pressing F1, Help.) 


In the center panel, the rows above and below the highlight show 
alternative nodes at the same level of the tree as the node you’re 
now on. To move to a row that’s now above the highlight, press 
the up ({) arrow. To move to a row that’s now below the 
highlight, press the down (|) arrow. When the list of alternatives 
is longer than the space in the center panel, the others come into 
view as you scroll by pressing up or down. 


To jump directly (without scrolling) to another item in the center 
panel, type a letter on the keyboard. The highlight moves to the 
next item starting with that letter. 
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In the right panel, you see nodes further out from the node you’re 
now on. To reach one of them, first press the right (+) arrow. 
That brings the right panel under the highlight. (Now the left 
panel shows the node you just came from.) 


When you’ve moved all the way to the end of a branch, the right 
panel is empty, indicating that there’s nowhere else to go in that 
direction. 


In the left panel, the row at the center (immediately to the left of 
the highlight) shows the next node rootward. When you’re moving 
outward through the tree, it’s where you just came from. 


To go back to a node in the left panel, press the left (—)arrow. 
That moves the left panel so it’s under the highlight. Then press 
up or down as necessary to highlight the alternative you want. 


When you’ve moved all the way back to the root of the tree (or 
when you’re just starting out) the left panel shows no other nodes. 
Instead, it’s used to display the Network General logo and 
copyright notice. 


As you can see in Figure 3-3, the main menu starts with one 
choice under the highlight and a list of alternatives above and 
below it. At this level of the tree, you can select one of the 
following major alternatives: 


@ Capture. This is the node under the highlight when you 
first display the menu. To the right are the subordinate 
choices attached to it. (Chapter 4 covers the Capture 
submenu.) 


Above the highlighted node are the following alternatives: 


e Cable Tester. Tests the network cable. (For more 
information, see “Using the Sniffer to Help Locate Cable 
Faults” in Chapter 4.) 


8 Traffic Generator. Loads the network with background 
traffic messages sent from the Sniffer. (For more 
information, see “Generating Traffic to Load the Network” 
in Chapter 4.) 


e Capture Filters. Directs the Sniffer as to which frames to 
keep and which to let go. (For more information, see 
“Setting the Capture Filters” in Chapter 4.) 


@ Trigger. Freezes the capture buffer during data collection. 
(For more information, see “Setting the Trigger” in Chapter 
4.) 
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Preparing to Capture 


Preparing to Display 


To Conclude Work 


Conventions in the 
Sniffer Menus 


Below the highlight are the following alternatives: 


e Display. Exhibits the current contents of the capture 
buffer. (The options for Display are covered in Chapter 5.) 


e Files. Saves or loads data or setups. (See Chapter 6 for 
complete information on files and directories.) 


e Exit. Terminates the current session. 


If you’re about to collect data, you should first move the highlight 
to Capture Filters to describe the data you want collected. To 
describe how to stop capturing and to freeze the capture buffer, 
use the Trigger submenu. Finally, to describe the real-time 
displays you want during capture and to start capturing frames, 
move the highlight to Capture. (Chapter 4 is devoted to the details 
of these choices.) 


If you’ve just captured some frames, you may want to move first 
to the Files option to save your captured frames to a file. If you 
want to display frames, but as yet have none in the capture 
buffer, you may need the Files option to load the capture buffer 
with a file of previously-saved frames. Then you're ready for the 
Display option and to examine the frames in the buffer. (Chapters 
5 and 6 are devoted to the details of these choices.) 


When you select Exit, work with the Sniffer terminates, and you 
return to the selection menu. But before you do that, you may 
want to save a record of the filters, triggers, or display options 
you’ve established in a file. Then at a future session, you recall 
that file and re-establish all the options as they were. To do that, 
first select the Files option before you exit, and then select the 
Save/Setups command sequence. (See Chapter 6 for additional 
information on these options.) 


The following conventions apply equally to the Sniffer’s main 
menu and to the various subordinate menus you may reach from 
it. 


e Enter key. At certain nodes in the menu tree, you need to 
press Enter, either to start the desired action or to open a 
window in which you'll supply further details. Wherever 
Enter is a possible response, the node is marked with the 
symbol <! (to remind you of the “return” symbol engraved 
on the Enter key). 


e Check marks. At certain nodes in the menu tree, you may 
select any number of alternatives from a list. Mach of the 
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items selected is checked thus: yv. Each item not selected is 
marked with an x. 


For a highlighted item, you reverse the current choice by 
pressing the space bar. 


When you wish to reverse the setting of many items at 
once, hold down the Alt key while you press the space bar. 
That reverses the setting of all items. 


e Radio controls. At certain nodes in the menu, you may 
select one from a list of mutually exclusive alternatives. 
They’re called radio controls by analogy with the push 
buttons on a radio which don’t let you tune in two stations 
at once. 


A set of mutually exclusive choices is shown linked by a 
vertical bar with the symbol |» at the one selected. For a 
highlighted item, you select it (and deselect the one 
previously selected) by pressing the space bar. 


e First-letter jump. When you type a letter of the alphabet, 
the highlight jumps (in the current menu) to the next row 
that starts with that letter. Or you can just scroll there 
with the up or down arrows. 


A menu item that has none of these markings serves as a heading 
for a branch of the menu tree. You select it as a route to one of 
the items subordinate to it, but you can’t take action until you 
move the highlight to an item marked with a <!. For example, 
when you select Files in the Main Menu (Figure 3-3), you have to 
move from there to one of its subordinate menus before you can 
start action. 


The function keys F1 through F10 provide a quick and convenient 
way to indicate the action you want next. For each menu or 
display, the current meanings of the function keys are shown in a 
band across the bottom of the screen. The screen shows a label 
for each key that is active at the moment with a caption to 
describe its action. (Keys that are not active simply disappear 
from the display.) 


In almost every situation, FI calls up a list of help topics. You 
may scroll to the topic you want and there press Enter to see a 
brief discussion of that topic. (The only exception is that you can’t 
signal for help while the Sniffer is actively capturing data. You 
have to press Pause to suspend data capture temporarily or must 
wait until you’ve finished capturing.) 
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Chapter 4. Capturing Frames, 
Generating Traffic, 
and Testing the Cable 


Capture and Display 


Files of Captured Frames 


This chapter tells you how to capture frames from the network 
and to bring them to the capture buffer for analysis. You can also 
load the capture buffer from a file of frames captured earlier, 
either by “replaying” their capture or by bringing them in directly. 
It also covers the various options for real-time display. Finally, it 
describes how to make the Sniffer generate rapid-fire traffic in 
order to load the network. 


The last part of this chapter describes how to use the Sniffer to 
help locate Ethernet cable faults and how to capture at high speed. 


Chapter 5 describes how to display the frames once you have 
them in the capture buffer and to interpret the display. 


The Sniffer divides the analysis of network frames into two broad 
phases: 


° Capture phase. The Sniffer accumulates arriving frames 
and meters their arrival. It also tabulates them by source 
and destination and by the occurrence of certain errors. 
This chapter is primarily concerned with capture. 


e Display phase. Frames are no longer being captured, and 
the capture buffer is frozen. You can select, display, and 
interpret the frames already in the capture buffer. The 
display phase is described in Chapter 5. 


It’s possible to save the contents of the capture buffer as a file and 
use it later for display or for playback. Such a file is called a 
capture file. To each such file, you can assign whatever name you 
wish for the first eight letters. Its name has the extension .ENC. 
The procedure for creating a file is described in the section headed 
“Saving a File of Frames” in Chapter 6. 
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Capture Overview 


Live Capture: 


Playback: 


Either Way: 


There are two ways to capture frames: 


e Live from the network, 
or 

e Playback from a saved file of frames that were captured 
previously. 


Either way, the arriving frames go first to a capture filter. Those 
that pass through the filter are stored in the capture buffer.* 


If the Sniffer isn’t already connected to the network, connect its 
network adapter to an available connection point on the network. 
(The cable and connector required are discussed in Chapter 3.) 


In the capture menu, replace From <Ethernet> with the name of 
the file to be played back. (See the section, “Identifying a 
Playback File.”) 


Regardless of whether you capture live from the network or by 
playing back a saved file, you can set options and controls before 
you start capturing: 


e Capture filters. Tell the Sniffer which frames to keep and 
which to discard. (You can do that explicitly or by loading a 
previously-saved setup file.) 


A capture filter may select frames by one of the following: 


> DLC address (source, destination, or both). 

> Low-level protocol. 

> Pattern of characters at a particular position in the 
frame. 

> Defects (presence or absence). 


When you set several filters, the frames that get through 
are those that meet all the criteria: the station address, the 
protocol, the types of defective frames, and the pattern you 
specify. 


° Trigger. Set conditions to tell the Sniffer how you want it 
to stop capturing frames and to freeze the capture buffer for 
analysis. (That, too, can be done explicitly or by loading a 
previously-saved setup file.) 


You can also load a file of previously-saved frames directly to the capture 
buffer, bypassing the displays generated during capture. The procedure is 
described under “Loading a File of Previously-Saved Frames” in Chapter 5. 
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e Frame Size. Set a maximum number of bytes from each 
frame that the Sniffer will retain in the capture buffer. 


Protocol information is almost always in the leading bytes, 
followed by the accompanying data (that is, the message 
text). You may tell the Sniffer to truncate frames longer 
than a length you specify. You may want to do that to save 
room in the capture buffer. On a very busy network, 
truncation may be necessary to avoid losing some frames, 
since under certain conditions they may arrive faster than 
the Sniffer can store them at full length. 


® Display options. Specify the form, scale and units of 
measurement for presentations, counters, and the real-time 
traffic-density bar graph during capture, and determine 
whether to use audible clicks to mark the arrival of frames. 


When you’re ready to start capture, press F10, or move to 
Capture in the main menu and there press Enter. 


When you're collecting data to look at a specific problem, you'll 
probably want to set up a capture filter and a trigger before you 
start capturing. But when you’re just browsing to check the 
network’s traffic load, you can start capturing right away without 
trigger or filters. 


From the main menu, move up to select Capture filters. From 
there, move to the right to select one of the three types of capture 
filter: Station address, Protocol, or Pattern match. 


During capture, the only addresses the Sniffer can consider are 
those at the lowest level, DLC, specifying the frame’s immediate 
sender and destination. The Sniffer accepts a frame when: 


e Its DLC source matches the From address you name 
and 
e Its DLC destination matches the To address you name 


(or also the reverse, if you check Reverse direction) 
and 


e It’s a member of the broadcast/non-broadcast categories 
you’ve checked. 


Before you set an address filter, the Sniffer accepts all frames 
from any station to any station by default (Figure 4-1). To 
change that, use the arrow keys to highlight the line labeled From 
or the line labeled To, and there press Enter to open the SELECT 
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STATION window in which you can select an address (Figure 4-2). 





Figure 4-1. Default settings of capture filters for station address. 


When you press Enter on one of those lines, the Sniffer opens a 
window in which you can see the list of names and station 
addresses in your current names file (Figure 4-2). If the name 
you want appears in the list, scroll to it and press Enter. The 
Sniffer closes the window and inserts the name you’ve selected in 
the display. 





Figure 4-2. Menu to select a station for a stati 


When you want the Sniffer to accept frames from any source, 
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select the line that says Any station. This entry isn’t really part of 
the names file, but the Sniffer always shows it at the head of the 
list of stations. It always has type DLC and XXXXXXXXXXxx for its 
address field. When you select Any station, the Sniffer won’t test 
that field, so any frame will pass. 


When the station you want to select isn’t on the list, select the line 
marked New Station, and press Enter. The Sniffer opens a window 
in which you can enter a symbolic name and its hexadecimal 
station address (Figure 4-3). 





Figure 4-3. Window for inserting a new name and station address. 


Watch out: Inserting a new name in this manner revises the 
name list in working memory. It doesn’t update the stored file of 
names, so the revision is temporary. If you want to make it 
permanent, select Display in the main menu, then Managing 
Names, and finally Save names. 


Within the Sniffer’s name list, there can be only one name for 
each DLC address. When you specify a name for a station that 
was already named, your new name thereby replaces the former 
name. (You can edit the list of names from the Edit names 
submenu described in Chapter 6.) 


Instead of directing a frame to another specific station, the sender 
may instead direct it to a multicast address. A multicast address 
may serve as a collective name for a group of several stations. It 
may be a role played by one or another station, by no station, or 
by all stations (for example, “Broadcast”). 


A DLC multicast address is distinguished by having a 1 in the 


low-order bit of the first byte, so that in its hexadecimal display 
the second character is odd (that is, 1, 3, 5, 7, 9, B, Dor F). No 
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individual station has an address with that bit on. In the Sniffer’s 
name table, you may assign a symbolic equivalent to a multicast 
address (for example “Error Monitor” or “LAN Manager”). Of 
course, that name will turn up only as an addressee, never as the 
sender of a frame. 


Protocols in the Capture In the main menu, move to Capture Filters and then to Protocol. 

Filter You'll see in the right panel the list of Ethernet types and SAPs. 
The names on the list are the types and SAPs for which protocol 
interpreters have been installed on your Sniffer. During the 
display phase, the Sniffer will automatically determine whether it 
should display a frame as an Ethertype or as a SAP. 


A check mark indicates a type or SAP that the Sniffer will accept. 
By default, all are checked initially (Figure 4-4). 


Below the three menu panels, you can also readily view which 
protocol suites have been installed on your machine. You can see 
the Network General part number for each protocol suite 
displayed in the instruction box. 





Figure 4-4. Menu to select Ethertypes and SAPs for the capture filter. 


Using the up or down arrows, move to each entry you want to 
change. Press the space bar to reverse its status. (Alt-space 
reverses all of them.) 


During capture, the Sniffer accepts any frame whose type is 
checked on this list. 


Watch out: Specifying a protocol in this manner revises the 
capture filter in working memory. It does not update the stored 
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file containing your Sniffer setup, so the revision is temporary. If 
you want to make it permanent, move to Files in the main menu, 
then to Save, and finally to Setup when you have completed this 
and other changes to your setup. (See Chapter 6 for more 
information.) 


To capture only frames containing a particular pattern, move to 
Capture filters and then to Pattern match. The pattern is two 
consecutive bytes at the offset you indicate. By choosing the 
appropriate offset, you can match on the type of frame, a code 
embedded in a low-level protocol within the frame, or portions of 
the address (for example, a common code shared by a class of 
addresses or the portion that identifies the manufacturer of the 
adapter). 


In the right panel to the right of Capture Protocol, you'll see a 
display of the current pattern and offset. By default, these are 
initially xxxx (“don’t care”) at offset 000 (Figure 4-5). 





Figure 4-5. Menu to specify pattern match for the capture filter. 


The pattern match filter may be set to pass only frames that. have 
the specified pattern or only those that do not. Move to the line 
marked Equals or Not equals, and press the space bar to select the 
one that’s highlighted and to, thereby, deselect the other. 


To specify the pattern to be tested, move the cursor to highlight 
Pattern and press Enter. The Sniffer opens a window that allows 
you to specify a new pattern. A pattern may occupy from one to 
four half-bytes (nibbles). Insert the pattern you want where the 
current pattern is displayed. You must compose your entry from 
the hexadecimal digits 0 to F or from the code, x, which means 
“don’t check this nibble.” 
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Figure 4-6. Inserting the text of a new pattern. 


Mattern match 


To identify a pattern, you must also describe its position. Its 
position is measured as its offset to the beginning of the four- 
nibble pattern, stated in bytes. Enter only the first three 
hexadecimal characters for the offset. They are entered 
calculator-style, that is, from left to right but while the cursor 
remains in the right-most position. This is in contrast to the entry 
of the pattern itself where characters are entered typewriter-style, 
that is, from left to right as the cursor moves from left to right. 





Figure 4-7. Specifying the offset for a pattern in the capture filter. 


In the example shown in the preceding figures, the pattern being 
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matched is the IP Ethertype. Such a frame has a pattern of 0800 
at offset 00a. 


Watch out: Specifying a pattern in this manner revises the 
capture filter in working memory. It does not update the stored 
file containing your Sniffer setup, so the revision is temporary. 
When you have completed this and other changes in your setup, 
select Files in the main menu, then Save, and finally Setup if you 
want to make it permanent. 


Filtering Defective During capture, you may elect to filter so that the Sniffer includes 

Frames or excludes various types of defective frames (see Figure 4-7a). 
You indicate your selection by checking those you will accept from 
the following list: 


® Good frames. Frames which have none of the defects 
listed below. 


° Bad CRC frames. Frames with bad cyclic redundancy 
checks. 


e Fragments. Collision fragments (frames shorter than 60 
bytes). What the Sniffer sees are the remnants of the 
collision of frames from two transmitting stations, if that 
remnant was big enough to contain at least part of the first 
address. Collision “noise,” which terminates during the 8- 
byte preamble, is not reported by the Sniffer. 


e Bad alignment. Frames received with a length that is not 
a multiple of 8 bits. 





-7a. Menu for filtering defective frames during capture. 
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Setting the Trigger 


The startup default is to capture defective frames as well as good 
frames. However, you may check any number of the four 
alternatives. The filter then passes each frame you check. 


During the display phase, each filtered defective frame is marked 
in both the Summary view and the Detail view of the particular 
frame. (See the sections, “Flags Options” and “Frame Error 
Reports,” in Chapter 5.) 


The trigger pattern consists of one to four consecutive half-bytes 
(nibbles) at a specific position in a frame. The pattern and its 
location are defined in the same way as the pattern used in the 
capture filter; you set them in a similar window. In the main 
menu, select Trigger (Figure 4-8). Then move right to the list of 
trigger options. The pattern xxxx indicates no trigger regardless 
of the offset. 





Figure 4-8. Default settings of the trigger. 


To set a trigger pattern, use the up or down arrows to highlight 
Trigger, then move right to select a line in the list of trigger 
options. These allow entries for Pattern, Offset, Equals/Not Equals, 
and Stopping Capture. 


For example, to trigger on a frame reporting an SMB error in a 
3Com 3+ system, you might first set the capture filler to pass 
only XNS frames. Then set the trigger to freeze the capture 
buffer when it finds that the primary SMB return code is not 
equal to 00 (zero means “normal”). In an SMB frame, the 
primary return code is a single byte located at offset 03p. 


(There’s also a two-byte secondary return which may provide 
amplification of the primary return.) 
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Since the event you want to detect is a frame that does not have 
00 as the primary return code, use the arrows to highlight Not 
equals, and press the space bar to select it (and to deselect 
Equals). 


To fill in the trigger pattern, highlight Pattern and press Enter. 
The Sniffer opens a window in which you can enter the 
appropriate pattern (Figure 4-9). 





Figure 4-9. Window in which to supply trigger pattern. 


The window has space for two bytes. Since the test involves only 
one, Jeave xx in the other. The code xx means that the byte is not 
checked (so the Equals/Not equals setting doesn’t apply to it.) 


When you move the cursor to highlight Offset, the Sniffer opens a 
window in which you may write the desired offset (Figure 4-10). 
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Figure 4-10. Window to supply the location (offset) of the trigger pattern. 


Positioning the Trigger 
Frame in the Capture 
Buffer 


To complete the description of a trigger, indicate when you want 
the Sniffer to stop capturing data. If the Sniffer stops capturing 
as soon as it sees a matching frame, the trigger frame is, 
therefore, the last frame to arrive. The other frames in the buffer 
are those that preceded the trigger. 


Conversely, if the Sniffer doesn’t stop until the trigger frame is 
about to be pushed out the far side of the capture buffer, the other 
frames in the buffer will be those that followed the trigger frame. 


To indicate your choice, move the cursor to highlight the one you 
want, and press the space bar to select that one and to deselect 
the others. Figure 4-11 shows a selection that will stop capture 
when 75% of the buffer space is used by frames that preceded the 
trigger, and the remainder by frames that followed it. (Note that 
the value you specify determines the proportion of buffer space 
before or after the trigger frame, not the number of frames.) 
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he rule for stopping capture. 


When the Sniffer matches the trigger pattern, it reports that fact 
by changing the label in the upper left corner of the screen from 
CAPTURING tO TRIGGERED (Figure 4-17). In the display, the trigger 
frame is marked with the letter T (see the section, “Flags Option,” 
in Chapter 5). Later, during display, you can jump to the trigger 
frame and, perhaps, mark it so as to display time relative to it 
(see the section, “Searching and Jumping,” in Chapter 5). 


The capture buffer never contains more than one frame marked T. 
If your reply to Stopping Capture permits capture to continue after 
a trigger frame has been spotted, and the Sniffer subsequently 
admits other frames that match the trigger pattern, only the first 
is considered the trigger frame, and only the first is reported and 
marked. However, if you press Pause when a trigger frame is in 
the buffer, and then later you press Resume without clearing the 
buffer, the arrival of a later trigger frame is reported; the later 
frame is marked with a rT (and the T is removed from the earlier 
trigger frame). 


This option is most often used when you haven’t set a trigger. 
Nevertheless, it still has effect if you combine it with a trigger 
pattern. 


When you select Stop when full, but the capture buffer fills before 
the Sniffer finds a trigger frame, capture nevertheless ceases. No 
frame is marked with a T. 


When you select Stop when full and the Sniffer finds a trigger 
frame before the capture buffer is full, it continues capturing 
frames until it has filled the buffer. The trigger frame is marked 
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Continuous Capture 


Setting the Capture 
Menu Options 


with a T as usual, but its position in the buffer depends solely on 
how full the buffer is when the trigger frame arrives. 


This setting instructs the Sniffer not to stop capturing frames 
until you signal manually from the keyboard. If a trigger frame 
happens to arrive, the first such frame is, as usual, reported and 
marked with a T. It enters the capture buffer. However, capture 
doesn’t stop, so other frames arriving after it may push it out of 
the buffer before you call a halt. 


Before you press the button to start capture, you may select from 
options in addition to the appropriate filters and a trigger. 


You can specify the source of capture, either a live capture or a 
playback file; whether or not you want the Sniffer to emit audible 
clicks indicating the arrival of data; the maximum size of the 
frame you'll keep; and some of the elements of the screen that the 
Sniffer will display during capture. 


Like the particulars of the filters and the trigger, you can include 
the state of these options as part of a saved setup, so you can 
restore options at once, either by creating your own customized 
startup setup or by loading a saved setup file. (See the discussion, 
“Loading and Saving Setups,” in Chapter 6.) 


During capture, the Sniffer screen displays some elements which 
are common to all Sniffer screens as well as some elements which 
are not common to all. You can choose to view network activity 
either as a display of counts by individual stations, as a display of 
counts by pairs of sending and receiving stations, or as a moving 
“skyline” graph. Accompanying each of these choices, you will see 
a traffic density bar graph, a set of traffic counters, and an 
elapsed time counter. 


When the capture buffer is full, the Sniffer sounds a brief three- 
note chime. Capture may halt or may continue (depending on 
what you’ve elected in the trigger setting). If capture continues, 
the earliest frames in the capture buffer are discarded to make 
room for those newly accepted. The Sniffer continues to update 
the tabulations so that they show the totals for the entire period in 
which capture took place (not just the frames remaining in the 
capture buffer). 


To prepare to capture frames, select Capture in the main menu 
(Figure 4-12). The Sniffer doesn’t actually start capturing frames 
until you press F10, New Capture, or move to Capture and there 
press Enter. 
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Figure 4-12. Capture option in the main menu. 


Automatic Cable Test 


Source From Which 
Frames Are Captured 


Before you press Enter or F10, check the panel at the right. It 
specifies the type of display you’ll see during capture. If it’s 
satisfactory, start capture by pressing Enter or F10. But if you 
need to revise the settings of the capture display, first use the 
arrow key to move to the panel at the right, and there set the 
options you want. 


An automatic test of the cable will occur just before the first 
capture of a session. If the cable passes the test, capture will 
proceed as usual. If it does not pass the test, then the following 
warning message will appear: There appears to be a cable or 
transceiver fault. In the event of test failure, check the cables, and 
make sure that you are not trying to use the Thin Ethernet BNC 
connector, unless the jumper on the network card has been 
changed. 


Besides the automatic test, you can also test the cable at other 
times during a session. See the section, “Using the Sniffer to Help 
Locate Cable Faults.” 


The Capture menu includes provision to specify the source from 
which frames are captured. The source is visible in the bottom of 
the right panel in Figure 4-13 as the notation From <Ethernet>. 


Capturing with the source, From <Ethernet>, is called live 
capture. That’s the default. 
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Figure 4-13. Capture menu showing field labeled From indicating source from which frames 
will be captured. 


Alternatively, you can replace Ethernet by the name of a file 
containing already-captured frames. From any of the saved 
capture files, you can regenerate a real-time display of meters and 
counters, just as though the packets were arriving from the 
network in real time. Capturing from a file rather than live from 
the network is called playback. 


Playback permits you to experiment with the display options that 
are available during capture even when you’re not capturing “live” 
frames. It also makes a convenient way to demonstrate a 
particular sequence to your colleagues or to introduce the Sniffer 
to people who haven’t used it. At a tutorial session based on 
playbacks, you can: 


® Observe the dynamics of capture, including changes in 
traffic density and the accumulation of traffic counts. 


® Experiment with capture filters to weed out extraneous 
frames. 
@ Experiment with triggering (that is, freezing the capture 


buffer when a particular trigger pattern is received). 


e Experiment with recording only part of each captured 
frame. 


To run a playback, you don’t have to be connected to the network, 
so you can use it for experiment, training or demonstration even 
when the network is down or when you’re not connected to it. 
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Identifying a Playback In the main menu, move the highlight to Capture and then to the 

File detail panel to the right of Capture. Move the highlight downward 
to the line marked From. Beside the word From you'll see the 
name of the source from which you’re going to capture data. If 
you haven’t yet reset this option, it says <Ethernet> by default 
(Figure 4-13). 


There press Enter to bring up a list of alternative sources from 
which to capture frames. You'll see a menu that includes all the 
capture files in the current directory (Figure 4-14). Each file has 
the file extension, .ENC. 


The menu also lists the names of any subdirectories within that 
directory. To see what’s in one of the subdirectories, move the 
highlight to it, and press Enter. The notation, .. <DIR>, in the top 
row indicates the directory one step nearer the root directory. 





Figure 4-14. Window showing list of trace files from which you may elect to capture durin, 
playback. 


Move the highlight to the name of the file you want to play back, 
and press Enter. That records your choice and takes you back to 
the panel of Capture options. You'll now see your selection named 
in the From field (Figure 4-15). 


(See Chapter 6 for more information on files and directories.) 
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Figure 4-15. Capture menu showing playback file selected. 


Audible Clicks 


Truncating the Captured 
Frames 


When you want to return to capturing live data from a network, 
use the same procedure, but choose <Ethernet Network> at the 
top of the list instead of one of the files. 


During capture (or playback) the Sniffer emits a clicking sound to 
indicate the arrival of data. The sound gives an informal 
impression of the density of traffic. However, before you start 
capture, you may turn off the clicking sound. Move the highlight 
to Audible clicks in the Capture window, and there press the space 
bar to reverse the setting from y (clicks) to x (no clicks). 


When the frames you’re capturing are long, they may fill up your 
capture buffer before you’ve collected a good enough sample. 
That’s most likely to happen when the frames involve substantial 
data transfers on the network. Usually you’re interested only in 
the headers and not in the data that’s being transferred. In this 
situation, you want partial frame capture. You specify the 
maximum number of bytes you’ll accept from each frame; the 
Sniffer discards the excess characters before they can reach the 
capture buffer. 


To get partial capture: in the main menu, move the highlight to 
Capture and then to the panel to its right. Within that panel, 
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move up to the menu item, Frame Size (Figure 4-16), and from 
there move rightward to the next panel to select one of the six 
options: 

® Not more than the first 32 bytes. 

© Not more than the first 64 bytes. 

e Not more than the first 128 bytes. 

e Not more than the first 256 bytes. 


® Not more than the first 512 bytes. 


e Whole frame. 





Figure 4-16. Menu to limit the length of captured frames. 


Real-Time Displays of 
Network Traffic 


Move the highlight to the length you want, and there press the 
space bar to register your choice. These are radio controls, that 
is, selecting one automatically deselects the one previously 
selected. 


For all the frames accepted by the capture filters, the Sniffer 
presents a real-time display of meters, counters, and other 
measures of network activity. You have a variety of choices for 
real-time display, some of which are unique to a particular display 
and some of which are common to all. 


First of all, you can choose from among three elements for real- 
time display which differentiate the general format of one display 
from another: 
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Counter Overflow 


e Pair counts. For each pairing of DLC addresses that 
actually occurs in the frames or kilobytes accepted, the total 
traffic between them in each direction. (This is the default 
setting.) 


e Individual counts. For each DLC source address, the 
total traffic it sent in terms of frames or kilobytes. 


e Skylines. Two moving “skyline” graphs. One shows the 
number of frames or kilobytes being captured within a time 
interval which you set, and the other shows the number of 
stations active within the same time interval. 


In addition to the differentiating elements of real-time displays, 
there are other elements which appear on all displays: 


e Traffic density bar graph. Displays traffic as kilobytes 
per second, as frames per second, or as a percentage of the 
network’s available bandwidth. You can display all three 
measures of traffic density on either a linear or on a 
logarithmic scale. 


e Traffic counters. Just above the traffic density bar are 
two rows of counters displayed by the Sniffer. These 
include counters for the number of good frames seen by the 
Sniffer as well as for defective and lost frames. In addition, 
there are counters for the number of kilobytes and frames 
accepted by the Sniffer. 


e Capture buffer utilization. Updates the percentage of the 
capture buffer used by the Sniffer continuously. 


e Elapsed time counter. Shows total elapsed time (in hours, 
minutes, and seconds) during which frames are captured. 
The time counter is located in the top right corner of the 
capture display, it does not advance during a pause, and it is 
reset to zero whenever you clear the counters. 


In the event that a counter overflows, the left-most digit is 
automatically replaced by the “greater than” symbol, >, and the 
counter begins to increment again starting from 0. Only one 
overflow is indicated in this way. For example, a reading of 
>00385 indicates that at least one overflow took place and that 385 
units have been counted since the last overflow. 
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Pair counts The Pair counts table is updated in real-time as frames are 
accepted. Before capture starts, the table is empty. As svon as a 
frame is accepted, the Sniffer notes which station sent it and to 
whom it’s addressed. When a frame with that sender-addressee 
pair has been seen before, the Sniffer updates the count for the 
corresponding slot in the table. But when the frame represents a 
station pair that hasn’t previously been heard from, the Sniffer 
creates a new entry in the table. The Sniffer builds the table as 
frames are accepted. Within the screen, a particular entry’s 
position depends on the arrival sequence. Positions in the table 
are filled from top to bottom, then left to right. 


When the capture buffer is full, the Sniffer sounds a brief three- 
note chime. Capture may halt or may continue, depending on 
what you’ve elected in the trigger setting. If capture continues, 
the earliest frames in the capture buffer are discarded to make 
room for those newly accepted. The Sniffer continues to update 
the tabulations so that they show the totals for the entire period in 
which capture took place, not just the frames remaining in the 
capture buffer. 


When you elect Pair counts, the Sniffer allocates half a line for 
each pair (Figure 4-17). If the first frame received was sent from 
station A and was addressed to station B, the Sniffer creates an 
entry for the a/8 pair like this: 





In this example, the number 1 indicates traffic from a to B. At the 
same time, the Sniffer reserves a space to count traffic in the 
reverse direction from B to A. 





Figure 4-17. Pairwise tabulation during capture by sending station and addressee. 
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Individual Counts 


Although traffic can only originate from a physical station, it may 
be addressed to a group (for example, Broadcast) or to a role (for 
example, Error Monitor), When such names appear in the 
addressee field of a pairwise tabulation, you'll see traffic 
addressed to those names but never traffic from them. 


This table has 16 rows and, hence, a total capacity of 32 pairings 
of sender and addressee. 


If the incoming frames have more distinct pairs than that, they go 
to the capture buffer as usual, but they’re not included in the 
screen tabulation. 


Warning. The two types of traffic counts, Individual counts and 
Pair counts, can sometimes appear to lag behind the counter for 
Frames accepted (see the section, “Traffic Counters”). Two 
circumstances under which this may occur are: 


e All the space on the display is filled with station addresses 
or names. The Sniffer keeps collecting data on incoming 
frames, but the new stations’ counters are not represented 
on the screen. 


e Frames arrive at the Sniffer so fast that they simply 
outstrip the station counters’ capacity to keep an accurate 
count. The two rows of counters above the traffic density 
bar will always be accurate, however. 


If you select Show Kbyte counts, the numbers in the counts for 
pairs and for individuals represents Kbytes, not frames, and, thus, 
won’t agree with the number for Frames accepted. 


The Individual counts table is updated in real time as frames are 
accepted. Before capture starts, the table is empty. As soon as a 
frame is accepted, the Sniffer notes which station sent it. When a 
frame with that sender has been seen before, the Sniffer updates 
the count for the corresponding slot in the table. But when the 
frame represents a station that hasn’t previously been heard 
from, the Sniffer creates a new entry in the table. The Sniffer 
builds the table as frames are accepted. Within the screen, a 
particular entry’s position depends on the arrival sequence. 
Positions in the table are filled from top to bottom, then left to 
right. 


When you elect Individual counts, traffic is tabulated solely 
according to the station that sent it (Figure 4-18). The Sniffer 
divides the screen into four columns and adds entries from top to 
bottom in the first two columns, and then from left to right, as it 
notices new senders. 


This table has 16 rows and, hence, a total capacity of 64 stations. 


If the incoming frames have more distinct senders than that, they 
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go to the capture buffer as usual but they’re not included in the 
tabulation. 





Figure 4-18. Individual tabulation by sending station during capture. 


Skylines The Skylines option allows you to see the real-time display as 
moving “skylines.” Above the traffic density bar you see two bar 
graphs in addition to the traffic density bar graph: the top one 
shows the number of frames or Kbytes being captured within a 
time interval which you set and with unit sizes you specify. The 
bottom graph shows the number of stations active, i.e., stations 
that have sent frames in the interval and in selected unit sizes. 
Furthermore, you have the alternatives of an earlier view or of a 
later view of the data represented by each of the two graphs. 


Figure 4-19 shows the Skylines option. In this case, the time 


interval is set for a one second update and the unit size is set for 
one frame per unit. 
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CAPTURING 





Figure 4-19. Skylines graphs during capture. 


The Capture/Skylines submenu permits you to set a time interval 
for the display of the data which the skyline represents. The 
choices are: 


e 1 second update. 
® 1 minute update. 
e 1 hour update. 


When you run the Sniffer with the Sfylines option, five function 
keys offer additional choices during capture. 


F2_ Select display. Toggles between the two “skyline” graphs. 
F5 Scale up. Adjusts the scale of the selected graph upwards. 


F6 Scale down. Adjusts the scale for the selected graph 
downwards. 


F7 View earlier. Scrolls both graphs to data recorded before 
the portions of the two skylines visible on the screen. 


F8 View later. Scrolls to an “earlier view” of a skyline 
rightward and toward NOW. 


(More information on these keys, and on the other functions keys 
available during capture, is available in the section, “Options 
During Capture.”) 
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You have a choice from among three ways of reporting units of 
traffic density. Show frame counts and Show Kbyte counts affect 
the tabular counts, including the Individual counts and the Pair 
counts formats. They also affect the top “skyline” graph and the 
dynamic traffic density bar graph. Show NW usage affects only 
the traffic density bar graph. The options are: 


e Show frame counts. The tabular counters show the actual 
numbers of frames up to 999,999. The top “skyline” graph 
shows the number of frames being captured within a time 
interval which you set. The traffic density bar graph shows 
frames per second with a maximum of 3,000 frames per 
second. 


e Show Kbyte counts. The tabular counters show kilobytes 
transmitted with fractional amounts rounded up to the next 
higher integer multiple of 1024 bytes. The top “skyline” 
graph shows the number of kilobytes being captured within 
a time interval which you set. The traffic density bar graph 
shows kilobytes per second with maximum of 1000 
Kbytes/sec. 


(Note that the sum of the individual tabular counters and 
the counter for total kilobytes may occasionally be different. 
This is due to rounding off.) 


e Show NW usage. The display shows frames or kilobytes 
as described above, but the traffic density bar graph shows 
percentage of total network bandwidth (1,250 Kbytes/sec) 
from 0 to 100%. 


During capture, the display shows a continuously updated 
horizontal bar graph of network utilization during the last second. 
The graph shows the current reading as a solid bar and the 
maximum reached since capture started as a dotted bar. 


The bar graph uses the units selected (frames per second, 
kilobytes per second, or percentage utilization). In addition, you 
can select to display the units on either a linear or a logarithmic 
scale. 


A switch on the Capture menu permits you to present the units 
selected (frames per second, kilobytes per second, or percentage 
utilization) on either a linear or a logarithmic scale (Figure 4-12). 
The switch affects both the top Shylines graph and the traffic 
density bar graph. Figure 4-19 shows a logarithmic scale, 
whereas Figure 4-21 shows a linear. 
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The advantages of the logarithmic scale are: 


e Displacement of one unit represents the same proportional 
change in traffic density regardless of where on the scale it 
occurs. 

e Small values are more visible. 

Traffic Counters On the first row just above the traffic density bar graph, the 


Sniffer displays: 


Good frames. Frames which have none of the defects 
listed below. 


Fragments. Collision fragments (frames shorter than 60 
bytes). What the Sniffer sees is the remnants of the 
collision of frames from two transmitting stations, if that 
remnant was big enough to contain at least part of the first 
address. Collision “noise,” which terminates during the 8- 
byte preamble, is not reported by the Sniffer. 


Misaligned. Frames received with a length that is not a 
multiple of 8 bits. 


Bad CRC. Frames with a bad cyclic redundancy check. 


Lost frames. A frame whose arrival was reported at the 
adapter but was not otherwise recorded. Some frames may 
be lost when the traffic density is so high that some arriving 
frames outrun the buffers and processor on the Sniffer’s 
adapter. (To avoid this when it is important to capture 
every frame at high traffic rates, see the section, 
“Highspeed Capture.”) 


On the second row just above the traffic density bar graph, the 
Sniffer displays: 


Kbytes accepted. The total number of kilobytes accepted 
since capture began, including both frames still in the 
capture buffer and those discarded to make room for later 
arrivals. 


Frames accepted. The total number of frames accepted 
since capture began, including both frames still in the 
capture buffer and those discarded to make room for later 
arrivals. 


Buffer used. The percentage of buffer space used by the 
frames so far captured. 


At any given time, the sum of four of these counters (Good frames, 
Fragments, Misaligned, and Bad CRC) represents the number of 
frames seen by the Sniffer, regardless of whether they were 
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passed or accepted by the capture filters. 


The counters for Fragments, Misaligned, and Bad CRC increment 
according to a preset priority. If a frame has more than one type 
of defect, the Sniffer counts only one of the defects. The order of 
priority is set such that the Sniffer counts as follows: 


e Fragments. Fragment frames are counted first. 
e Misaligned. Frames with misalignment errors are counted 


if they do not contain fragment errors. 


e Bad CRC. The Bad CRC counter increments only if none 
of the other types of defect are present in the frame. 


Therefore, if you choose no filters for Good frames, Bad CRC 
frames, Fragments, or Bad alignment in the Capture filters menu, 
then the sum of the Good, Fragments, Misaligned, and Bad CRC 
counters will equal the count for Frames accepted. The sum also 
represents the total number of frames seen by the Sniffer whether 
or not you have selected those filters. (See also the section, 
“Filtering Defective Frames.”) 


During the display phase, some counted frames may have special 
marks. In the Summary view, you can see flags for lost frames, 
collision fragments, misalignment errors, and frames with bad 
CRC. A Detail view of a counted frame also reports the type of 
defect in the last line of the DLC interpretation. (See “Flags 
Options” and “Frame Error Reports” in Chapter 5.) 


The Sniffer uses a distinct chiming signal to announce each of the 
following events: 


e Trigger found. 
e Buffer is 100% full. 
© Capture has stopped. 


These chimes are not affected by the control for clicks. If you’ve 
checked Audible Clicks, the Sniffer emits clicks during capture to 
provide an impression of the density of traffic. 


When you first start the Sniffer, it sets up a definition table of 
station addresses and their symbolic names. A file from which 
definitions can be read has a name whose extension is -END. 
(Initially, the Sniffer builds the table by reading from the file 
STARTUP.END.) While it’s recording entries in the counter table, the 
Sniffer looks up each address in its working definition table, and 
substitutes the symbolic name it finds there in its displays. 


For an address retained in the capture buffer, but not represented 
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Naming Stations 


Capture Buffer Storage 
Space 


in its table of definitions, the Sniffer does two things: 


e Represents that station in the counter display by its 
hexadecimal address rather than a symbolic name. 


® Adds the new address to the definition table but with 
blanks in the field for its symbolic name. 


The first time the Sniffer captures data on your network, stations 
may appear as numeric addresses. To avoid cluttering the names 
table, the number of addresses with blank names entered during 
capture is limited to 50 at each address level. 


You can make the Capture screen easier to read by giving each 
station a name. After you’ve completed capture, go to the Display 
menu, select Manage names, and there edit the entries in the 
definitions table. 


You'll see there at the head of the list the DLC addresses that the 
Sniffer has encountered but for which it had no symbolic names. 
You can edit those entries to provide symbolic names. Then, when 
you go to display data from the capture buffer, the display 
routines will augment the station addresses with the symbolic 
names you’ve provided. 


Watch out: The definitions table thus edited is the working copy. 
It won’t be retained next time you start the Sniffer unless you 
explicitly request to Save names and, thereby, rewrite the file, 
STARTUP.END. (See “Managing Names Used in Displays and 
Filters” in Chapter 6.) 


Information on available buffer storage space for frames during 
capture is now readily available on the Capture menu just above 
the Frame size option. The amount of space varies according to 
the number and size of protocol interpreters installed in your 
Sniffer (Figure 4-20). 
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Figure 4-20. The amount of buffer storage space available for frames during capture. 


Options During Capture During capture, the following function keys are active: 


F2 


F4 


F5 


Select display. When you run the Sniffer with the Skylines 
option, F2 is labeled Select display and toggles between the 
two skyline graphs to select a graph on which to use the 
Scale up and the Scale down capabilities of F5 and F6. The 
name of the selected graph is highlighted. 


Clear screen. The function of F4 varies somewhat 
according to which real-time display option you select: 


> If you select either the Individual counts format or the 
Pair counts format, the Sniffer removes the counter 
table from the screen, and the process of counting 
starts over, building a new counter table. 


> If you opt for the Skylines format, I’4 erases the bars 
of both the top and the bottom graphs, and new 
graphs begin. 


In all cases, F'4 resets the other counters above the traffic 
density bar to 0, erases the high mark (represented as a 
dotted bar) left by the traffic density bar, and resets the 
counter clock to 00:00:00. All start incrementing anew. 
However, the capture buffer is unaffected, and new station 
names added to the names table remain there. 


Scale up. When you display in the Skylines format, Scale 
up adjusts the bars of the selected graph upwards; that is, it 
elevates the peaks on the skyline. Each time you press F5, 
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F6 


F7 


you select an increasingly smaller number of units of 
measurement and, at regular steps, a successively smaller 
size of unit. 


An important use for this option is viewing particularly 
large or particularly small amounts of network traffic in the 
time interval you selected prior to capture. By fine-tuning 
the graphical presentation, you can more readily pick out 
the peaks and the valleys of the skyline. 


If you choose Show frame counts prior to capture on the 
Capture menu, the unit sizes you can specify on the top 
“skyline” are: 


> frames. One unit is one frame. 
> Kframes. One unit is a thousand frames. 
> Mframes. One unit is a million frames. 


If you choose Show Kbyte counts prior to capture, then your 
options for unit size are: 


> Kbytes. One unit is a kilobyte. 
> Mbytes. One unit is a megabyte. 
> Gbytes. One unit is a gigabyte. 


On the bottom “skyline,” the graph for presenting the 
number of stations currently sending data on the network, 
the choices for unit size are: 


> #stns. One unit is one station. 
> K#stns. One unit is a thousand stations. 


Scale down. Adjusts the scale for the selected “skylines” 
graph downwards; that is, it flattens the peaks on the 
skyline. 


View earlier. Scrolls both graphs to data recorded before 
the portions of the two skylines visible on the screen. After 
new portions of the skylines are generated at the right edge 
of the graph and disappear under the left edge, they are 
“frozen” for subsequent perusal. The “earlier” part of a 
skyline you view after scrolling leftwards is, therefore, an 
exact reproduction of the original. 


Prior to selecting 7, you see the word NOW between the 
two “skyline” graphs, on the right side of the screen, and 
with arrows pointing to the right edges of each of the two 
graphs. NOW means the present moment in which the data 
represented by the skyline just emerging at the right edge of 
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the window is generated by the network. 


After enough data has been captured for its graphical 
representation to disappear under the left edge of the 
window, you can select F7. You see that the up and down 
arrows are gone and that NOW is followed by an arrow 
pointing rightward and by a number. The number indicates 
how much “later” in time is NOW, or the moment at which 
the most current part of a skyline is being generated, and 
represents that time in terms of units of the time interval 
you selected in the Capture/Skylines submenu. 





Figure 4-21 depicts the Skylines display after selecting F7. 


When NOW gets to be 150 time units later, the Sniffer must 
begin discarding data. The skyline will scroll left to keep the 
oldest data at the left edge. 


F8 View later. Scrolls an “earlier view” of a skyline rightward 
and toward NOW, or the moment at which the most current 
part of a skyline is being generated. When you reach NOW, 
the skyline will once again scroll automatically and will keep 
NOW at the right edge. 


F9 Pause. Toggles between Pause during capture — allowing 
access other Sniffer menus and options—and Resume 
capture. This suspends capture so that arriving frames are 
not seen, but it leaves the capture buffer and the counter 
tables unchanged. From the paused state (see below), you 
can resume capture if you wish, perhaps after changing the 
way traffic is counted (which resets the counters but doesn’t 


Chapter 4. Capturing Frames, Generating Traffic, and Testing the Cable 85 


Ethernet Version 


Options During Pause 


change what’s in the capture buffer). 


F10 Stop capture. After capture has stopped, you may save 
the contents of the capture buffer to a file or display what’s 
there. If you subsequently start a new capture, the present 
contents of the capture buffer will be discarded (but the 
Sniffer asks you to verify that you mean to discard them 
and lets you withdraw the request). 


When you press F9, Pause, during capture, you may choose from 
among several function keys visible on the screen. Some of them 
permit you to add more frames to those already captured, and 
some do not. 


Fl Help. Provides information for using the Sniffer. 


F3 Data display. Terminates capture, discards the counters 
and starts display of the frames in the capture buffer. 


F4 Clear screen. Resets the timer and discards the counter 
tables but does not discard data from the capture buffer 
(same as F'4 during capture, above). 


F5 Menus. Terminates capture, discards the counters, and 
shows you the main menu. Frames in the capture buffer 
are unaffected. From the main menu, you may elect. to save 
the capture buffer in a file, to edit and to save the revised 
name table, to start display of the capture buffer, or to 
choose any of its other options. 


F6 Capture options. Takes you to the screen that permits 
you to choose options for the screen tabulation of incoming 
data. If you change the options, doing so also resets the 
counters (like F4, above). You may then, if you wish, 
resume capture. 


F9 Resume. Resumes the examination of incoming frames, 
accumulating those accepted to the capture buffer and 
adding to the counters (which may or may not have been 
reset during the pause). 


F10 New Capture. Discards the capture buffer and the 
counters (but leaves the working copy of the name table 
unaffected) and starts afresh with the process of capture. 


If you have not saved the contents of the capture buffer, the 
Sniffer shows you a screen asking whether it is OK to discard the 
frames now accumulated there. If you assent, it goes ahead, 
discarding the capture buffer and starting the process of capture 
afresh. If you want to save the frames in the capture buffer, you 
should press Esc to abort this command and then press F5 to 
return to the main menu where you can select Files and then Save. 
After that, you can again press F10 to start capture if you wish. 
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There may be occasions where the network is working at peak 
capacity for an extended period of time, and you risk losing 
important data during capture. The Highspeed mode switch on the 
Capture submenu allows you to bypass some functions (i.e. the 
counters and the indicator for the percentage of the buffer used 
which you see on the real-time display) in order to ensure a 
complete sample of data. The presentation of those numbers and 
the filtering and slicing of frames are delayed until after you’ve 
paused or stopped capture. 





Generating Traffic 
to Load the Network 


Figure 4-21a. Display and counters operative during highspeed capture. 





Figure 4-21a shows the Sniffer in action during highspeed capture. 
As you can see, only two counters are operative during highspeed 
capture: 


e Frames seen. Represents frames seen by the Sniffer, 
regardless of whether they could be passed or rejected by 
the capture filters. 


6 Align/CRC errors. Tallies both frames which are misaligned 
and frames which have bad cyclic redundancy checks. 


The Traffic Generator permits you to load the network with 
background traffic messages sent from your Sniffer. You can 
specify the addressee, the total length of the frame, and the 
interval between frames in milliseconds. You can also specify to 
whom the frames are addressed and the content of the first 
sixteen bytes. In that fashion, you can generate frames to which 
no station should respond or frames that appear to the recipients 
to have a particular type. 


Chapter 4. Capturing Frames, Generating Traffic, and Testing the Cable 87 


Ethernet Version 





88 


Figure 4-22 shows the panel in the main menu from which you 
select the Traffic Generator. Pressing Enter at any of the options 
listed on the right permits you to fill in the value you want or to 
select a destination from the table of DLC destination addresses. 





Figure 4-22. Panels showing options for the Traffic Generator. 


Address: 


Size: 


Delay: 


Frames: 


The options are as follows: 


Pick one from the list of DLC addresses in the Sniffer’s name 
table. If the address you want isn’t yet on the list, you can amend 
the list of addresses by selecting New Station. The address you 
choose may be the address of a specific station, a multicast address 
such as “All Routers,” or the all-station broadcast address. 


The total length of the frame in bytes from 12 (the minimum) to 
1514 bytes. The length of the smallest valid Ethernet frame is 60 
bytes, but shorter frames occur as collision fragments, and the 
Sniffer is capable of generating them. If you do specify a value 
between 12 and 60 bytes, you will get a warning that anvther 
station may pick these up as collision fragments. 


The number of milliseconds between the end of one frame and the 
start of the next from .04 to 1000. 


The number of frames to be sent. You can designate the number 
to be sent between 1 and 999999999 or specify 0 for INFINITE. 
The default is INFINITE. 
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Thirty-two hexadecimal characters specifying the sixteen bytes 
that follow the 6-byte destination and 6-byte source. The first two 
of these specify the Ethertype. For example, 0800 identifies the IP 
Ethertype, while 0600 identifies XNS. (Alternatively, in IEEE 
802.3 format, the first two bytes are the 802.2 length followed by 
the 802.2 header.) 


After you complete selection of your options and return the 
highlight to Traffic Generator, press Enter to start the Sniffer 
loading the network in the way you’ve specified. When it starts, it 
devotes full attention to the task and so can’t do anything else. 
You'll see a screen showing that traffic generation is taking place 
(Figure 4-23). The Sniffer continues sending frames until you 
press Esc to stop it and return to the main menu. 





The format of a frame sent by the Traffic Generator is illustrated 
in Figure 4-24. It shows a frame captured by another Sniffer on 
the network a few microseconds after the originating Sniffer sent 
the frame in response to the menu shown in Figure 4-22. 


In an Ethernet frame, the first twelve bytes contain the DLC 
source and DLC destination addresses. (In the example shown in 
Figure 4-24, the first Sniffer addresses the frame tv itself, so both 
addresses appear as 00 00 65 02 00 01.) 


Then come the sixteen bytes elected in the panel that generated 
the traffic (Figure 4-22). The first two bytes contain the 
Ethertype. In the example, it’s the invalid type 88 88, visible in 
the hex window at positions 0c and op. 
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Figure 4-24. Display of a captured frame generated by another Sniffer. 


Following the 12 bytes of addresses and the 16 bytes supplied by 
the sending Sniffer, the rest of the frame consists of 00 bytes as 
necessary to fill out the total length and a sequence number at the 
end. 


Sequence Number in The last four bytes of each frame sent by the Sniffer’s Traffic 

Each Generated Frame Generator contain a sequence number shown in Figure 4-24 as 00 
00 24 F5. (The sequence number is part of the message that the 
sending Sniffer generated and not a DLC frame number.) 


The four bytes form a 32 bit unsigned integer, starting with the 
most significant byte. The sequence number of the frame shown 
in Figure 4-22 is thus 9458. 


Using the Sniffer The Sniffer includes in the main menu an option to check and 

to Hel p Locate report cable faults (Figure 4-24a). This feature is in addition to 

Cable Faults the automatic cable test which occurs immediately prior to the 
first capture of a session (see the section, “Automatic Cable 
Test”). 


When you select Cable Tester and there press Enter, the Sniffer at 
intervals emits a pulse and listens for the echo characteristic of 
certain types of faults. That is, the Sniffer includes a time-domain 
reflectometer. 
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The test runs continuously until you terminate it by pressing Esc. 
As the status of the cable changes, the Sniffer updates its display. 
It needs no intervention or request from the keyboard. While the 
Sniffer detects no fault, the display appears as shown in Figure 4- 
24b. 





Figure 4-24b. Display when the Sniffer detects no cable faults. 


The Sniffer is able to detect a fault in the cable between its 
adapter and the transceiver to which the Sniffer is connected. 
You can also detect in an open line or a cable short in the network 
cabling beyond the transceiver (Figures 4-24c and 4-24d). 
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However, you cannot test for faults, open lines, or shorts on 
segments separated from the segment the Sniffer is on by a bridge 
or a repeater. 


The Sniffer is able to deduce the probable distance to an open line 
or a short by noting the delay between its test pulse and the echo 
generated by the fault. Translating that into distance requires 
knowing the speed at which the signal is propagated along the 
cable and that varies with the cable. The Sniffer reports the time 
in nanoseconds and computes two estimates of the distance along 
the cable from the Sniffer’s network adapter to the fault. One 
estimate assumes standard Ethernet cable with a propagation 
time of 0.79c. The other assumes thin cable (“Cheapernet”) with 
a propagation speed of .66c. The constant c represents the speed 
of light in a vacuum, about 0.3 meters/nanosecond. 





Figure 4-24c. Sniffer report of an open cable. 
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Figure 4-24d. Sniffer report of a cable short. 


Once the Sniffer has given you its estimates of distance, you have 
to interpret them. Since the resolution of the device producing the 
timings is 50 nanoseconds, distance is in effect reported to 
approximately the nearest 10-12 meters. Distance is the distance 
along the cable from the Sniffer in either direction (and along any 
of the cable’s branches). When the Sniffer is connected near the 
center of a network, there may be several stations at about the 
same distance. 


To help you interpret the Sniffer’s report at a time when you 
really need it, it is useful to run some calibration tests in advance. 
Deliberately introduce a cable fault at a known location (for 
example, by disconnecting a cable and leaving it without a 
terminator). Note the distance that the Sniffer reports. Prepare 
and save a table of several such observations, as a reference 
against which to compare the Sniffer’s report when there’s a real 
problem. This is especially useful when it is difficult to estimate 
cable distance because the cable is concealed (for example, behind 
furniture, in the walls, above the ceiling, and so on). 


Limitations: 


e The Sniffer readily detects an open line and produces a 
steady diagnostic display. It often (but not always) detects 
a short; the reflection characteristic of a short is harder to 
discriminate from a normal signal and, hence, is not always 
detected. 


® Certain intermittent defects in the cable can produce what 
appears as a jittering display at the Sniffer, as the Sniffer’s 
rapidly-repeated test pulses are assigned different 
diagnoses. Transceivers vary in the way they transmit the 
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test pulses and their echoes, and this variation in turn 
produces variation in the behavior of the cable tester; most 
transceivers produce useful results, but some do not. Also, 
a collision anywhere on the network which coincides with a 
test pulse from the Sniffer appears momentarily to the 
Sniffer as an open line. However, this should produce only 
a momentary flicker in the Sniffer’s test report. 


® The distances reported by the cable test may be inaccurate 


because of test pulse distortion caused by imperfect 
connectors, transceivers, or cables. 
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Chapter 5. Displaying and 
Interpreting the Captured Data 


This chapter describes the various ways you can display and 
analyze the network frames that you’ve captured. (The Sniffer 
also provides real-time displays of meters, counters and other 
measures which summarize and describe the rates at which data 
are arriving; they’re described in Chapter 4.) 


To manage how frames are viewed, or to select which frames to 
look at, you start from the Display branch of the main menu (see 
Figure 5-1). However, to save the current contents of the capture 
buffer to a file, or to load a saved file into the capture buffer, you 
start from the Files menu. Its entry point is visible just below 
Display in Figure 5-1. 





Figure 5-1. The main menu showing the Display option and its principal branches. 


The Display Menu The Display menu shows you first your choice of ways to view the 
captured frames (see the right panel in Figure 5-1). Views are 
described later in this chapter. The menu also offers a choice of 
filters to select the frames to be displayed, a print option for 
printing a report on frames in the capture buffer, and an option to 
manage names and to help make displays more readable. (These 
choices are mostly visible in the lower portion of the right panel in 
Figure 5-1.) 


Once you’ve selected the options for display, you then move the 


highlight back to Display, and press Enter to view the captured 
data. 
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Deciding Which Set of 
Captured Data to Display 


Setting the Display 
Filters 


However, before pursuing any of these issues, consider first where 
the capture buffer gets its frames: by capturing them from the 
network or by bringing back to the capture buffer a file of frames 
that were captured earlier. 


Before you can display or analyze them, frames must be in the 
capture buffer. You can display frames that have just arrived 
(and may not have been saved). Alternatively, you can load into 
the capture buffer a saved file of frames captured earlier. 


When you load a saved file, the file you load replaces whatever is 
then in the capture buffer. (So if you want a record of the capture 
buffer, you must save it before you load something else.) 


While you’re displaying the contents of the buffer, the Sniffer 
can’t write new data there. Displaying, therefore, suspends the 
capture of data from the network. 


For more information on loading and saving files with the Sniffer, 
see “Saving and Loading Frames and Setups” in Chapter 6. 


Either before you start the display, or as the display proceeds, you 
can establish a display filter. It selects a subset of the frames in 
the capture buffer and limits the display to those. 


When you subsequently save the contents of the capture buffer to 
a file, you have the choice of saving all the frames in it (regardless 
of the display filter) or just the frames that were accepted by the 
display filter then in effect. 


It’s probably easiest to set up some sort of display filter and to 
select your initial form of display before you actually start 
displaying frames on the screen. However, it’s not hard to 
change filters or display options as you go along, after you've 
started the display. You simply press F6, Display options, during 
display, and that opens a menu window which is superimposed 
upon your current display (see “Options During Display”). 
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You can see the Display/Filters submenu in Figure 5-2. 





Figure 5-2. Menu to establish display filters. 


Criteria for Filtering The display filter passes each frame which meets all of the 
following criteria: 


e Address level. Every frame on the network contains both 
the address of the station to which it’s addressed and the 
address of the station which sent it. They are included at 
the DLC level. However, a frame may also contain other 
addresses. Certain protocols permit a frame to include 
within it a message written according to a higher-level 
protocol, and that protocol may provide an addressing 
scheme of its own. 


To illustrate: one of the situations in which this is likely to 
arise is when frames are being relayed through a gateway. 
At the DLC level, a frame’s source and destination may be 
the gateway stations responsible for the current leg of its 
journey. Within a DLC frame, there may be an XNS 
message embedded. Its source and destination addresses 
are those of the original sender and the ultimate recipient, 
rather than the stations involved in this segment of the 
journey. (In some higher-level protocols, a frame may be 
addressed, not just to a machine, but to a process running 
on that machine.) 
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You can identify one or more protocol levels at which an 
address must occur in each displayed frame. Set. a check 
mark beside the name of each protocol in which the frame 
must contain an address. (If you don’t set this control, the 
Sniffer assumes by default that you’re interested in 
addresses at the DLC level which is present in every frame.) 


Address filter. You can identify a source and/or a 
destination address that must occur in each displayed frame. 
(To be accepted, the address must occur at one of the 
protocol levels accepted by the Address level filter.) 


Filtering on DLC-level addresses can be done during display 
or during capture. Filtering on higher-level addresses is 
possible during display but not during capture. 


When you specify an address, you may write it as one of the 
symbolic addresses you’ve provided the Sniffer or (for an 
address for which you’ve provided no symbolic equivalent) 
by writing its numeric station address. 


The filter passes frames that were sent from the addresses 
you mention, to the addresses you mention, or between the 
addresses you mention. 


Protocol. You can identify one or more protocols which 
must be present in each frame displayed. Set a check mark 
beside the name of each protocol you wish to accept. The 
filler passes a frame that contains any of the levels you 
mention. 


During display, the Sniffer is able to filter for any embedded 
protocol that its protocol interpreters recognize. (However, 
during capture, it is able to filter only on the lowest-level 
protocol.) 

Pattern Match. You can specify a pattern of up to four 
half-bytes which must be present (or, optionally, absent) at 


a particular position in the frame. 


Defective Frames. You can check any number of the four 
types of frame: 


ca Good frames. 

> Bad CRC frames. 
b Fragments. 

> Misaligned Frames. 


The filter passes each type only if it has a check mark 
beside it. 
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The procedures for setting the address filters, protocol filters, 
pattern filters, and defective frame filters are the same as those 
for setting capture filters, described in Chapter 4, “Setting the 
Capture Filters.” You should turn to that chapter for details. 


Note that although the procedures are the same, you see a wider 
range of choices than when you’re setting capture filters when you 
come to select a protocol or address for a display filter. That’s 
because during display you can filter on higher-level addresses or 
embedded protocols. Because the capture filters can’t check those, 
they don’t appear in the Capture/Filter menus. 


When you’re selecting a destination or source address, each 
address consists of a type and an address. You have to select the 
line that contains the appropriate combination of type and 
address. 


Watch out: Sometimes the name table has the same symbolic 
name for addresses that occur at different levels; be sure you 
highlight the correct type-and-address combination when you 
indicate your selection. (Types of addresses are discussed further 
in the section, “Managing Names Used in Displays and Filters,” in 
Chapter 6.) 


To set the address level filters from the main menu, highlight 
Filters and then Address level (Figure 5-3). 





Figure 5-3. Display filters menu showing a list of address levels. 


When you move the highlight to Address level, you see to the right 
a list showing the alternatives you may select. It starts with the 
lowest level, DLC, present in all frames. You may check as many 
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Address Level Filter 
Affects Names in the 
Display 


Setting the Protocol 
Filter 


levels as you wish. When you leave a check-mark on DLC (which 
is the default), every frame passes the address-level filter, since 
every frame has a DLC address. When you remove the check 
from DLC, you see only frames that contain one of the checked 
address types. (If you accept only frames of a type that is not 
represented in the capture buffer, you'll see the message, No 
frames selected for display.) 


Setting the Address level filter also affects the name that. the 
Sniffer uses in the Summary view of each frame. One name is 
shown as the source and one name as the destination for each 
field. The name that appears is the one corresponding to the 
highest of the levels checked in the address level filter for which 
there is a corresponding address in the frame. If that name has 
been assigned a symbolic equivalent in the working name table, 
that’s what the Sniffer shows. Otherwise, it shows the actual 
address in the format appropriate for that level. 


The display shows all the protocol levels that your particular 
Sniffer can interpret. That includes both those supplied by 
Network General and also any additional protocol interpreters you 
may have installed (see Appendix C). 


The procedure to set a protocol filter for display is just like the 
procedure to set a protocol filter for capture (Chapter 4, “Protocols 
in the Capture Filter”). However, during capture, the Sniffer’s 
filter detects a protocol only at the lowest level, whereas during 
display it can detect a protocol at any level. For that reason, the 
list of protocols may be considerably longer. The choices shown in 
the menu (Figure 5-4) are those provided by the _ protocol 
interpreters installed on your particular Sniffer. Because in some 
cases the same protocol may occur at more than one level, the list 
does not arrange them hierarchically by level. 
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Figure 5-4. Display filters menu showing list of protocol levels. 


Note that the Network General part number for each installed 
protocol suite is displayed in the instruction box below the menu 
panels. 


The category Other SAP selects a frame whose SAP is not covered 
by any of the other protocols on the list. 


Similarly, the category Other Ethertype selects a frame whose 
Ethertype is not covered by any of the other protocols on the list. 


The Sniffer will automatically determine whether it should display 
a frame as an Ethertype or as a SAP. 


Three Ways to View There are three ways you can view frames. You can have just 
Frames one view on the screen or any combination simultaneously. The 
three views are: 


® Summary view. A short form of the hexadecimal and 
detail listings condensed so that each level fits on a single 
line. You may elect to show all levels of interpretation or 
only the highest level. 


e Detail view. The protocol is identified and standard fields 
within it are labeled and explained. Station addresses are 
replaced by their symbolic equivalents according to the 
address table you supplied in the file srarTuP.END. Since a 
low-level frame may contain higher-level frames within it, a 
single frame may require several levels of interpretation. 
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The Summary View 


e Hexadecimal view. All bytes of the entire frame are 
shown, accompanied by a transliteration to ASCII or 
EBCDIC text. 


The Summary view gives you a condensed view of your captured 
frames. In addition, you have a number of choices on the 
Summary submenu to format the Summary view and to facilitate 
your analysis of the data. The Summary submenu is visible in the 
right panel of Figure 5-5. 





Figure 5-5. Submenu for Summary view. 


In the Summary view, you can examine a number of frames on 
either side of the one you’ve currently selected (Figure 5-6). It 
abbreviates and condenses so that each level of description is 
forced into one line. The Summary view, thus, permits you to see 
at a glance the sequence and context of the frames, even though 
the individual descriptions are truncated. You can then examine 
individual frames in greater detail or skip over them, as you wish. 
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Figure 5-6. Summary view showing frame 35 in the context of neighboring frames. 


You can format the Summary view to view the Highest level only 
or not. Also you can put the display into the Two-station format or 
not. If you choose the Highest level only and the Two-station 
format together, you will see a screen something like that in 
Figure 5-8. Note that all levels of interpretation for each frame 
are not included. (See the section on “Multiple Levels” for more 
information on the display when you do not select Highest level 
only.) 


Within a Summary view, you also can search for any text string 
(see the section, “Searching and Jumping”). 


Two-Station Format When you’re studying the interchange between a pair of stations 
on the network, the pattern of dialog can be made clearer by 
arranging transmissions from one station on one side of the 
display and those in the reverse direction on the other (Figure 5- 
7). You do that by electing Two-station format for the Summary 
view. 
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Figure 5-7. Two-station form of the Summary view. 


Selecting Stations to 
Show in Two-Station 
Format 


Transmissions involving just the two stations are shown half- 
width, those sent from one on one side and those from the other on 
the other side. 


Frames to or from other stations, or frames sent without a specific 
destination (e.g., broadcast frames), remain in the usual full-width 
format. (In Figure 5-7, frames 1 to 16 are in the two-station 
format, whereas frame 17 is not.) 


When you elect. Two-station format, the Sniffer scans the capture 
buffer for the first frame that is directed to a specific addressee. 
The station that sent that frame gets the left side of the display, 
and its addressee gets the right side. 


If the first station-to-station message in the capture buffer 
involves some other pairing of stations, you should apply a display 
filter that limits the display to frames from the stations you want 
and then switch to the two-station format. 


To switch the left and right sides of the display, save the capture 
buffer to a file, and as you do so, set the range of frames to be 
saved so that the earliest station-to-station message is one sent 
from the address you want on the left and to the address you want 
on the right. Then load the file you just saved. 
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Multiple Levels In the Summary view (but not the others), the display is limited to 
the highest (that is, the most deeply embedded) level of 
interpretation by default. 


For example, a single DLC frame may contain within it an IP 
level and that, in turn, may contain a TCP level. With the Highest 
level only switch turned off, you see the TCP level, but not the IP 
and DLC levels that contain it. 


You can turn off the Highest level only view and see a summary of 
each level within each frame. You do that as follows: select the 
Display/Summary window, move the cursor so that Highest Level 
Only is highlighted (Figure 5-5), and press the space bar to 
remove the check-mark on that entry. (Pressing the space bar 
turns on the check mark when it’s off and turns it off when it’s 
on.) The effect on Summary display is shown in Figure 5-8. 


Turning Highest level only on or off has consequences for the Detail 
view as well. Turn to the section, “The Detail View,” for more 
information. 


Telnet C PORT=1042 <0B> 





Figure 5-8. Summary display with the highest-level-only restriction removed (here shown in 
two-station format). 


Use of Symbolic Names The first time the Sniffer captures data on your network, stations 
may appear as numeric addresses. To avoid cluttering the names 
table, the number of addresses with blank names entered during 
capture is limited to 50 at each address level. 


You can make a display screen easier to read by giving each 
station a name. After you’ve completed capture or load a file of 
previously saved frames, go to the Display menu, select Manage 
names, and there edit the entries in the definitions table. 
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Width of Symbolic Names 


You'll see there at the head of the list the DLC addresses that the 
Sniffer has encountered but for which it had no symbolic names. 
You can edit those entries to provide symbolic names. Then, when 
you go to display data from the capture buffer, the display 
routines will augment the station addresses with the symbolic 
names you’ve provided. 


Watch out: The definitions table thus edited is the working copy. 
It won’t be retained next time you start the Sniffer unless you 
explicitly invoke Save names and, thereby, rewrite the file 
STARTUP.END. (See “Managing Names Used in Displays and 
Filters” in Chapter 6.) 


The Summary view (unlike the Detail or Hexadecimal views) is 
arranged in fields, including a field for source and a field for 
destination. Where an address has been assigned a symbolic 
equivalent, the Detail view shows it (instead of a numeric or 
hexadecimal address). 


The Sniffer permits symbolic names to have any length, not 
exceeding 31 characters. Since the Summary view must assign a 
fixed-width field for each frame’s source and destination, you can 
stipulate the maximum length of a displayed name. The Sniffer 
adjusts the Summary view accordingly. When you limit the 
display to a small number of characters, there’s more room on the 
screen for the other fields. Conversely, when you permit longer 
names, the Summary view allocates a field of the size you say and 
displaces other fields further to the right. (You can still see 
what’s there by scrolling sideways, but it may not all get on the 
screen at once.) 


The Display/Summary menu (Figure 5-5) includes at top right the 
maximum width of station names in the Summary view. The 
default value is 12 characters. You may assign a width as small 
as 8 or as large as 31. 


You may have a frame whose display requires a name (symbolic, 
hex, or numeric) that is longer that the width you’ve assigned. In 
that case the Sniffer truncates the name. It shows the first part 
of the name but replaces the last two characters of the field by 
two dots (to show that the name has been truncated). 


To alter the size of the name field in the Summary view, move the 
highlight to Name width and there press Enter. The Sniffer opens 
a window in which you may write the maximum name length you 
want. 
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Flags Option The left-most column of the Summary display is used to post flags 
for various conditions. Before you select the Flags option, the 
Sniffer uses the column to display the r flag and the m flag. When 
you select Flags, the left-most column is widened to accommodate 
a maximum of six flags, including the T and m flags, and the 
column is entitled Flags (Figure 5-9). 


The Sniffer flag collection includes markers for the following 
conditions: 


M Mark flag. Marks the reference frame when you choose 
the Relative time or the Cumulative bytes option (see 
“Displaying Time, Network Utilization, and Size”). In the 
Relative time column, the time shown on all frames 
subsequent to the flagged frame is the difference between 
the two frames’ timestamps. In the Cumulative bytes 
column, the number shown on all frames after the flagged 
frame represents the sum of the bytes since the reference 
frame. You set the mark on the current frame by pressing 
F2. 


T Trigger flag. Marks the trigger frame when you set the 
Trigger option (see the series of sections beginning with 
“Setting the Trigger” in Chapter 4). 


F Fragment flag. Marks frames in the display which are 
collision fragments, if you did not elect to filter such frames 
out. 


A Alignment error flag. Marks frames in the display which 
are alignment errors, if you did not elect to filter such 
frames out. 


Cc CRC error flag. Marks frames in the display which are 
CRC errors, if you did not elect to filter such frames out. 


The markers for collision fragments, alignment errors, and CRC 
errors make visible in a Summary view information about frame 
defects which you may not otherwise see until you examine it in a 
Detail view. 


(For more information on collision fragments, alignment errors, 
and CRC errors, see “Filtering Defective Frames” in Chapter 4 
and “Setting the Display Filters” and “Frame Error Reports” in 
the present chapter. Look also in Chapter 4, “Traffic Counters,” 
to find out more about the above topics and about lost frames.) 


In addition, you can add your own flags to the Sniffer’s flag 
collection through a customized protocol interpreter. The Sniffer 
will flag the frames for you in the Summary display. (See 
Appendix C, “Extending Protocol Interpreters.”) 
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Figure 5-9. A two-viewport display showing the Flags column as well as a simultaneous 
display of Relative Time, Size, and Network Utilization. 


Displaying Time, 
Network Utilization, and 
Size 


To examine a network’s throughput, you have to be able to look at 
the timing of transmissions. In its Summary display, the Sniffer 
provides several alternative measures of time and throughput, 
selectable to match the situation. You can display combinations of 
these measures concurrently (Figure 5-9). The measures are as 
follows: 


Absolute time. When the Sniffer completes reception of a 
frame, it attaches a timestamp. The timestamp records the 
time according to the Sniffer’s internal clock at the moment 
the Sniffer recorded the end of the frame. All of the 
displays of time are computed from the absolute value 
recorded with each frame. Absolute time is displayed as 
hours, minutes, and seconds to the nearest tenth of a 
millisecond. (That’s also how time is shown in the Detail 
display.) 


Delia time. The time shown is the interval from the 
arrival of the preceding selected frame, in seconds to the 
nearest tenth of a millisecond. Note that because it’s the 
interval to the preceding selected frame, frames present in 
the capture buffer, but not displayed, don’t affect delta time. 


Relative time. The time shown is the difference (in 
seconds, to four decimal places) between the frame’s 
timestamp and the timestamp of the reference frame. The 
reference frame is marked by the letter m appearing to the 
left of the frame number. When you first display the buffer, 
the first frame is marked. You can mark a frame (and, 


108 The Sniffer: Operation and Reference Manual 


Ethernet Version 


thereby, remove the mark from any other frame) by 
pressing F2, Set mark, while you have the frame 
highlighted. 


Once you’ve marked a reference frame, you can always find 
it quickly with the display option, Jump to mark (see 
“Searching and Jumping”). 


@ Network Utilization. The number shown is an estimate of 
the percentage of the network’s bandwidth devoted to 
transmitting each frame now visible in the capture buffer, 
during a time interval that brackets the frame. 


You can set the size of the bracketing window around each 
frame. The allowable sizes are 1, 10, 100 or 1000 
milliseconds (Figure 5-10). For example, if you pick 100 
milliseconds, the value reported is the number of bits in all 
the frames whose arrival times are within +50 milliseconds 
of the arrival time of the frame you’re looking at, divided by 
the maximum number of bits that could be transmitted in 
that time and stated as a percentage. It’s thus a moving 
average. When you pick a small window, you'll see larger 
momentary fluctuations; a larger interval smooths them out. 


e Bytes. The number shown is the total number of bytes in 
the frame. 


e Cumulative Bytes. The number shown is the sum of the 
lengths of the displayed frames from the reference frame 
through the current frame (including both). When you 
haven’t marked a reference frame with F2, Set mark, the 
Sniffer counts from the first displayed frame. 


Once you’ve marked a reference frame, you can always find 


it quickly with the display option, Jump to mark (see 
“Searching and Jumping”). 
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Figure 5-10. Menu to select the form of time display, average network utilization, and bytes. 


The Detail View 


The estimate of network utilization, and the calculation of 
cumulative bytes, is based on a sampling only of the frames that 
pass your capture and display filters. To make sense of 
utilization, it’s important to 


® Exclude unrelated frames (for example, from other stations), 
and 

@ Include lower-level protocols that support a high-level 
transaction. 


Because they both require calculations involving many frames, 
you cannot. select Cumulative bytes and NW _ utilization 
simultaneously. 


When a frame contains several levels of protocol, the Detail view 
includes interpretation of all of them. Within the window, they’re 
arranged with outermost (lowest) level first. 


You can pre-determine the level which will be initially displayed 
when you open a Detail view of particular frames: 


e If you select Highest level only on the Summary view menu, 
the Sniffer scrolls the display in the Detail view so that the 
highest level is positioned at the top of the window, possibly 
concealing the lower-level displays. You can use the up or 
down arrows, or the page keys, to bring into view the parts 
that were concealed. 
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e If, on the other hand, you turn Highest level only off, the 
Sniffer remembers the level where you last left the highlight 
in the Summary view and automatically scrolls to that level 
when you choose a Detail view. If you do not set a level in 
the Summary view for automatic scrolling, then the display 
will default to the DLC level. Again you can use the up or 
down arrows, or the page keys, to bring the other levels into 
view. 


The frame shown in Figures 5-11 and 5-12 has a Data Link 
Control (DLC) level which contains within it an Internet Protocol 
(IP) level which in turn contains within it a Domain Name 
Services (DNS) level. The first view of the frame shows the Detail 
window scrolled to include the beginning of the highest level 
protocol (Figure 5-11). 





Figure 5-11. Part of the Detail view of the frame that is visible in hexadecimal in Figure 5- 
13. 


At the left edge of the Detail view, the Sniffer shows the protocol 
level it’s interpreting. Figure 5-11 shows the Detail view including 
the start of the DNS interpretation of that frame. By scrolling 
upward, you reveal the DLC and IP interpretations that precede it 
(Figure 5-12). 
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Figure 5-12. Scrolling reveals other levels of detail in the same frame. 


In the Detail view of the DLC level, the frame’s size, source, 
destination, and arrival time at the Sniffer are all shown together 
with various other control indicators contained within it. 


Frame Error Reports The Sniffer detects certain defects in a frame and reports them in 
the Detail view as part of the DLC report (although strictly 
speaking they’re characteristics of the frame as a whole, rather 
than of anything in the DLC protocol). When there are errors, the 
error report appears as the last line of the DLC interpretation 
(Figure 5-12). 


You can also find defective frames flagged in a Summary view 
when you elect the Flags option (see “Flags Option”). 


The possible errors which may be reported are: 


9 Fragment. The frame is shorter than the minimum length 
of 60 bytes and is presumed to be a collision fragment. 


a Bad CRC frames. The cyclic redundancy check included in 
the frame is inconsistent with the bits actually in the frame. 


@ Bad alignment. The number of bits received is not a 
multiple of 16, so the boundary between characters is 
ambiguous. 


The Sniffer’s protocol interpreters attempt to interpret whatever 
they find but may be misled by the error. Both capture filters and 
display filters can be set to pass or to accept frames containing 
these errors. 
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The Hex view shows each byte by its two-character description, 00 
to FF, with a blank between successive bytes. The bytes are 
arranged 16 to a row in a full-width table (8 to a row in a half- 
width table). At the left, the offset from the beginning of the 
frame is displayed in hexadecimal (Figure 5-13). 


Prev =8 Next 


Figure 5-13. Hexadecimal view of a frame. 


To the right, the same characters are displayed again, this time 
with interpretable characters shown by their ASCII or EBCDIC 
equivalents and all others by a dot. 


If you have frames for which EBCDIC translation would be 
appropriate, you can select that as follows: From Hex in the 
Display menu, move rightward. Move downward from ASCII to 
EBCDIC, and there press the space bar to record your choice 
(Figure 5-14). 
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Figure 5-14. Menu to select the translation of hex characters. 


Windows and Views 


Scrolling Within a 
Window 


Once you’ve decided on which view or views you want, you can 
then use the capabilities of the Sniffer’s windowing feature during 
display to further explore and to analyze the loaded file. 


Within a window, you can scroll through the frames in the capture 
buffer, bringing one at a time to the screen (or when you select the 
Summary display, a frame and its neighbors). 


The information for a window may require more display space 
than the window contains, especially when several windows are 
displayed at once and each one is small. By using the movement 
keys (arrow, page, home, end, and so on) you can scroll the data 
within the active window, both vertically and horizontally. 


t The up arrow moves you to frames that occur further up in 
a window with a Summary view. 


| The down arrow takes you to frames that are occur further 
down in a window with a Summary view. 


- The left arrow takes you to the left part of a window. 
> The right arrow takes you to the right part. 


You can also use two function keys for scrolling: F7, Previous 
frame, and F8, Next frame. These work regardless of the chosen 
windows or active window. (See “Options During Display” for 
more information on these function keys and how they work in 
different views.) 
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Frames are identified by their sequence in the capture buffer. The 
first frame is referred to as frame 1, the next as frame 2, and so 
on. 


If you want to move quickly to a frame, there is an option which 
allows you to reference it by this number (see the section, 
“Searching and Jumping”). 


You can also filter the frames to be displayed so that you see only 
the frames that meet certain criteria. (See the section, “Setting 
the Display Filters.”) Frames that don’t meet your criteria are 
still in the capture buffer, but they’re omitted from the display. 
Filtering out certain frames from the display doesn’t change the 
numbering of those that remain visible. For example, when the 
filter excludes frames 2 and 3, in the display you see frame 1 
followed by frame 4. 


When the display contains more than one window, the window in 
which the highlight is located is considered the active window. 


You move from one window to the next by pressing the Tab key. 
Each press takes you to the window below. When there are two 
viewports, going down from the lowest window on the left takes 
you to the top window on the right. Pressing Shift and Tab moves 
you in the opposite direction. 


Moving the highlight from one window to another makes the 
window at which you arrive the active window and deactivates the 
window you left. 


When you select two or three views at once, the Sniffer divides the 
screen into two or three windows, one above the other. In such 
multi-window views, the Summary window appears above any 
other window, and the Hex window appears below any other 
window (Figure 5-15). 
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Figure 5-15. Summary, Detail and Hex views shown in three windows. 


Scrolling in Simultaneous While you're displaying two or three views, all the active 

Views viewport’s windows scroll together when you change to another 
frame. For example, when you’re displaying both Summary and 
Detail, you might scroll the Summary window so that it shows the 
next frame. That causes the Detail window to show the next 
frame also, so that the windows remain in step. 


Similarly, when you shift the highlight in the Summary window to 
mark a different frame, the viewport’s Detail window and its Hex 
window both scroll automatically, so that the frame they show is 
the one which is highlighted in the Summary window. 


When you’re showing multiple levels within the Summary window, 
the report on a single frame may occupy several lines (one for 
each level). You can move the highlight from one level to the 
next, yet remain within the same frame. For example, you 
might move the highlight from the DLC level to the 1P level. 
When you do that, the Detail window scrolls also, so that the level 
at the top of the Detail window matches the level you’ve 
highlighted in the Summary window. 


Two Viewports You may want to hold one frame on the screen while you examine 

Side-by-side another frame elsewhere in the capture buffer. To do that, you 
open a second viewport. In the Display menu, select Two 
viewports. The second viewport appears to the right. Each of the 
displays is truncated to half width in order to accommodate both 
sets. 
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Figure 5-16. Menu to select two independent side-by-side viewports, each containing a 
Summary display. 


The menu screen you see in Figure 5-16 is available during 
display when you press F6, Display options (see the section, 
“Options During Display”). 


Figure 5-17; illustrates the use of two viewports to compare 
frames 5 and 8. 


OW 
6Disply.;7 Prev 8 Next 





Figure 5-17. Display with two viewports each containing a Summary window and a Detail 
window. 
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Highlighting Detail in the 
Hex View 


Figure 5-18. Two viewports, each with three windows. 


Using two viewports on a single screen, each containing multiple 
windows, doesn’t leave very much room for any particular 
window. However, it’s possible to take an enlarged look at the 
active window with F4, Zoom in, and then to return to the 
multiwindow overview by pressing F4 again. You can also use 
the Tab key to move from one zoomed view to another (see 
“Options During Display”). 


EO 00. BECEB OOOO 1B 49 lays: 
3 1B 59 36 6B 38 1B 59 23 .¥6k8.¥ 





Figure 5-18 illustrates the use of Two viewports to compare 
Summary, Detail, and Hex views of frames 5 and 8. 


When you have both Detail and Hex views of a frame, the Sniffer 
highlights the corresponding bytes in the Hex window as you move 
the highlight to the various parts of the Detail window at the same 
time (Figure 5-19). That makes it easy to see the correspondence 
between the hexadecimal bytes that the frame actually contains 
and the interpretation placed upon them. 


Since the Hex window also displays the offset of each line, you can 
readily deduce the address of each field as you see it highlighted. 
You may use this hexadecimal address as the offset for a pattern 
match. 
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Figure 5-19. Highlighting detail in the Hex window.. 


Options During During display, the following function keys are active: 
Display 


F1 Help. Provides assistance in using the Sniffer. 


F2 Set mark. Used to mark the reference frame with an 
when calculating Relative time and Cumulative bytes (see 
“Displaying Time, Network Utilization, and Size”). 


F4 Zoom in/out. Temporarily expands the active window to 
fill the entire screen. Especially when you have several 
windows open, the space for the individual windows may be 
too small to see much of the information. Pressing F4 
zooms to full-screen display of the active window; pressing 
F4 a second time restores the previous arrangement of 
windows. 


Once you’ve zoomed to a full-screen display of the active 
window among several opened windows, you can easily 
move to zoomed views of the other opened windows by using 
the Tab key. 


F5 Menus. Returns you to the Sniffer Main Menu. 

F6 Display options. Provides you with the basic set of display 
options found the Sniffer Main Menu but also makes 
available several auxiliary display options which permit you 


to: 


> Go directly to a specific frame number. 
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Searching and Jumping 


F7 


F8 


> Search for a text string in either a Summary view or 
in frame data. 


> Search for a pattern in a frame. 

> Jump directly to the m mark on the reference frame 
you select for a Relative time or a Cumulative bytes 
display. 

> Jump directly to the Trigger frame which is marked 
with a T. 


(See the section, “Searching and Jumping,” for further 
information on these choices.) 


Previous frame. Takes you to the previous frame. Only 
frames which pass the current display filter are shown, so 
pressing this key takes you to the adjacent visible frame, 
perhaps skipping over one or more that the filter rejects. 


In a Summary window which shows several frames at once, 
F7 moves to the neighboring frame, or to another level of 
the same frame, but it does so by moving the zone that is 
highlighted and by scrolling if the highlight is already at the 
edge of the window. 


In the Detail window and the Hex window, F’7 replaces the 
current display with the display for the neighboring frame. 


If you have multiple views within a viewport—i.e., 
Summary, Detail and Hexadecimal—and scrolling takes you 
to another frame, your Hexadecimal or Detail windows (if 
open) move to that frame, too. 


Next Frame. Takes you to the next frame. Otherwise it 
behaves in the same way as F7. 


F10 New Capture. Starts the capture process again. 


If you press F6 during display, the superimposed menu of Display 
Options includes several ways of searching and of moving rapidly 
to particular frames (Figure 5-20). 
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Go to Frame Number 


The other options on the menu are the same as those on the main 
Display menu, and they are conveniently located in the Display 
options submenu to give you quick access as you move around 
through the frames and the data. For more information on how to 
use them, see the appropriate sections of this chapter. 


When the frame you ask for (by number or because it’s the 
marked or trigger frame) is present in the capture buffer, but 
excluded by your current display filters, the display moves to the 
first visible frame after it or, failing that, to the first visible frame 
before it. 


To move directly to a frame whose number you know, select Go to 
frame nn. When you press Enter, the Sniffer opens an additional 
window in which you can write the number of the frame you want 
(Figure 5-21). It won’t let you ask for a frame whose number is 
larger than the number of frames in the buffer. 


(F or more information on frame numbers, see “Numbering of 
’ 
Frames.”) 
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Figure 5-21. Window in which to write the number of the frame to which you want to go. 


Search for Text To search for any text string, either in a Summary view or in 
frame data, select Search for text. Next move the highlight 
rightward then downward to the In summary text/In frame data 
switch (Figure 5-22), and press the space bar for either In 
summary text or In frame data. 


MMR: Ie St. 
20 165.0969 080014117032+¢FEFDFCFBFAF9 7??? ETYPE=F8F7 (Unknown) 





Figure 5-22. Text search function in the Display Options menu. 


Move the highlight to the Text = field, and press Enter. When you 
press Enter, an ENTER TEXT window pops up. Type in the 
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desired text, and press Enter again (Figure 5-23). To begin the 
search, move the highlight back to the Search for text item in the 
original menu, and press Enter. 


Your string can be as Jong as the available space in the window, 
and the Sniffer will search for any characters you can put into the 
window. However, be certain to enter upper and lower case 
exactly as you want them because the search is case-sensitive. 





Figure 5-23. Window for entering text to search in a Summary display. 


In the example above, the Sniffer will search for the text, 1cmp 
Redirect starting with the current frame. When the Sniffer 
successfully finds your string, it presents the message, Found at 
frame nn, and highlights the frame in the Summary view which 
contains the string. To repeat the search, simply select the Search 
for text menu option once again, and press Enter. When the search 
reaches the last frame on the display, it goes back to the first 
frame and continues the search. On the other hand, if the Sniffer 
does not find your string, it presents a Not found message. 


Search for a Pattern You can move to a frame containing a particular pattern. You set 
the pattern in exactly the same way you’d state it for a capture 
filter or trigger pattern (described in Chapter 4, “Pattern 
Matching in the Capture Filter”). 


Figure 5-24 shows a pattern to locate a frame in which the 
machine serving as a terminal emulator transmits the ASCII code 
for shift out (0£). In a Telnet frame, the first character of the 
data is at location 36 (hex). Of course, a pattern makes sense only 
in the context of a protocol. To confine your search to frames in 
which that pattern in fact means “shift out,” you have to set the 
display filter to pass only Telnet frames. 
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Figure 5-24. Specifying a pattern to jump to. 


Jumping to the Trigger 
Frame or to the Marked 
Frame 


Printing a Report 
on Frames in the 
Capture Buffer 


Jump to trigger takes you directly to the frame which was the 
trigger during capture, if there was one. If present, it’s marked 
with Tt in the Summary view. Jump to mark takes you to the 
frame you marked with an m or to the first frame if there is none 
marked. (You can set the mark on highlighted frame in a 
Summary view by pressing F2.) 


You can obtain a printed record of the Sniffer’s displays of the 
capture buffer. The basic steps for printing include specifying 
which frames you want included in the report, designating a 
destination of either a printer or a file, and indicating whether or 
not you want page titles included. 
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The options for the Print menu are visible in Figure 5-25. 





Figure 5-25. Menu to select printing of a report on frames in the capture buffer. 


The Print menu permits you to print all the frames in the capture 
buffer or to state a first frame and a last frame in order to print 
only a portion of it. The Sniffer assumes by default that you want 
to print frames between the current frame of the screen display 
and the marked frame of the screen display (or the first, when 
none is marked). To change the range of frames that the Sniffer 
prints, highlight From or To in the Print menu, and there press 
Enter. The Sniffer opens a window in which you may fill in the 
appropriate frame number (Figure 5-26). 
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Figure 5-26. Option to specify the range of frames to be included in a printed report. 


Your report can be sent directly to a printer or to a file (Figure 5- 
25). A report sent directly to a printer may be routed either to 
LPT1 or to COM1. LPT1 is for a parallel connection by way of a 
DB25 connector. COM1 is for a serial port via a DBY connector. 
If you use a serial port, you will also have to specify the rate (in 
baud) of communication and the mode. See the discussion of these 
matters in the printer manual or the DOS manual. 


If you choose to print your report to a file, a window like the one 
visible in Figure 5-27 appears when you select File and press the 
Enter key. You then type in a name for the file and press Enter 
again. Finally, move the cursor back to the Print menu item and 
press Enter to start the print process. The Sniffer automatically 
attaches a .PRN extension onto the file name for you. 
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Figure 5-27.Window to name the file when you choose print to a file. 


In general, the printed report contains the same information you 
can see displayed on the screen without the restriction of the small 
window or the requirement to scroll. However, note the following. 
points of similarity and difference between the screen display and 
the printed version: 


® The printed report starts with a record of the source of the 
data; that is, the date and time it was recorded and the 
word <Ethernet> (when the file was captured live from the 
network) or the name of the file (when the capture buffer 
was obtained from a saved file). 


e Like the screen display, the printed report shows each of the 
views you requested for a frame, then the same views for 
the next frame, and so on. However, the printer does not 
break views into the windows required for viewing on the 
screen. 


° A frame may contain several levels of protocol. In the 
Detail view, the printed version shows only those levels of 
protocol actually checked in your display filter and levels 
other than the highest only when you turn off Highest level 
only. 


To print all levels of the detail interpretation, you must turn 
off Highest level only and turn on all the protocol levels in 
the display filter. (By contrast, for any frame that the filter 
accepts, the screen permits you to scroll inside the Detail 
window to look at other levels of protocol that may be there.) 
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Figure 5-28 shows a printed report. For this report, frames 60 
through 70 were selected. It depicts a Summary view of the data. 


Sniffer data collected on 2/1/87 at 13:31:24, file D:\ENDEMO\TDEMO.ENC, Page 1 


SUMMRY Rel Time 


60 
61 
62 
63 
64 
65 
66 
67 
68 
69 
70 


-0.0090 
-0.0068 
-0.0046 
-0.0026 
0.0000 
0.0022 
0.0045 
0.0065 
0.0090 
0.0110 
0.0123 


Destination 


Pine C .. 
Tamalpais 
Tamalpais 
CHampel 

Pine C .. 
Tamalpais 
Tamalpais 
CHampel 

Pine C .. 
Tamalpais 
Tamalpais 


CHampel 
CHampel 
Pine C .. 
Pine C .. 
CHampel 
CHampel 
Pine C .. 
Pine C .. 
CHampel 
CHampel 
Pine C .. 


Source Summary 


DNS R ID=166 STAT=OK NAME=sail.stanford.edu 
ICMP Redirect (Redirect datagrams for host) 
ICMP Redirect (Redirect datagrams for network) 
DNS R ID=166 STAT=OK NAME=sail.stanford.edu 
DNS R ID=166 STAT=OK NAME=sail.stanford.edu 
ICMP Redirect (Redirect datagrams for host) 
ICMP Redirect (Redirect datagrams for network) 
DNS R ID=166 STAT=OK NAME=sail.stanford.edu 
DNS R ID=166 STAT=OK NAME=sail.stanford.edu 
ICMP Redirect (Redirect datagrams for host) 
ICMP Redirect (Redirect datagrams for network) 





Figure 5-28. Printed report of a Summary view. 
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Chapter 6. _ Files, 
Name Management and Directories 


Saving and Loading 
Frames and Setups 


Loading a File of 
Previously-Saved Frames 


Chapter 6 deals with the Sniffer filing system and with the 
management of station names. The Sniffer uses different files 
which are distributed in various directories. Some files give 
instructions to the Sniffer, while others store information. Some 
files you use all the time, and others you touch seldom, if ever. 
The section, “Managing Names Used in Displays and Filters,” 
gives detailed attention to working with station names from both 
within the Sniffer or with a DOS text editor. 


In previous chapters, there are brief discussions of saving data 
files and of loading the capture buffer with data previously saved 
in a file. The present section gives you detailed instructions how 
files are loaded and saved as well as how to work with setup files. 


To view a list of previously-saved files for putting into the capture 
buffer, first select Files, then Load, and then Data by using the 
arrow keys (Figure 6-1). 





a file. 


When you press Return, the Sniffer shows you a list of previously- 
saved capture files (Figure 6-2) and, perhaps, directories. The list 
is in alphabetical order. Capture files are identified by the 
extension, .ENC. The notation .. <DIR> in the top row indicates 
the directory one step nearer the root directory. Other entries 
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with <DIR> indicate subdirectories whose files you can examine by 
selecting that entry. Use the up or down arrows to move the 
highlight to the file you want. Alternatively, to jump directly to a 
part of the list, type a letter from the keyboard. The highlight 
moves directly to the next file starting with that letter. 


When you have highlighted the file you want, press Enter to load 
that file. 





Figure 6-2. LOAD DATA FROM panel with list of previously-saved files. 


The display lists all the capture files in the current directory (that 
is, the directory from which you started the Sniffer). 


Saving a File of Frames 
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While you have frames in the capture buffer (either because you 
just captured them, or because you loaded them from a file), you 
can select Files/Save/Data. You can save: 

e Everything in the capture buffer. 

e Only those frames that pass your current display filter. 

e Only frames within a particular range. (You set the range 


of frames to be saved in the same way that you set the 
range of frames to be printed.) 
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You indicate your choice by supplying values for From and To and 
by deciding whether to check Filtered only, as appropriate (Figure 
6-3). 





Figure 6-3. Menu for saving data files. 


Saving Your Current 
Setup 


You can select a range of frames to be saved. The beginning of 
the range can be the first frame in the buffer or a frame number 
which you specify. To set the beginning, move the highlight to the 
desired alternative, and press the space bar to select it. If you 
select the option From frame 1, a small window will open, and you 
can enter the frame number you want. You select the end of the 
range in the same way. If you want to save only filtered frames, 
then move the highlight to Filtered only, and press the space bar to 
insert a check (v). 


After you select your options, move the highlight back to Data, 
and press Enter. The Sniffer then prompts you for the name of 
the file to which you want your data written. If the file you name 
doesn’t yet exist, the Sniffer creates it and writes it. If the file 
already exists, the Sniffer asks whether to discard its former 
contents. 


Your “setup” is the particular constellation of display options, 
filters and controls you’re using. You can save the setup to a file. 
Later, you can load that file, thereby restoring all those options to 
the values they had when you saved it. 


To save you current setup, select Files, then Save and then Setup. 
The Sniffer opens a window in which it asks you to write the 
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Contents of a Setup File 


Using a Saved Setup File 


name under which the file should be saved. It supplies the .ENS 
extension for each such file. The Sniffer creates a file with that 
name and writes a record of your setup. If the file name you 
choose already exists, the Sniffer prompts you with a warning and 
lets you either escape and re-name the file or overwrite the 
existing file. 


The setup file records what you had chosen for every one of the 
options settable in the menus by a checkmark or a radio control. 
Therefore, some items are included in a setup file, and some are 
not: 


e Included in a setup file are: 
> Capture options. 
> Capture filters (including the addresses of source and 


destination stations, and a pattern and offset). 


> Trigger options (including the trigger pattern and 


offset). 
> Display options (including views and levels). 
> Display filters (including the addresses of source and 


destination stations, and a pattern and offset). 


> Printer options. 
e Excluded from a setup file are: 
> The path you may have set for locating the directory 


of files to be loaded or saved. 


> The capture buffer; that’s done independently by the 
command sequence, Save/Data. 


> The name table; that’s done independently by the 
command sequence, Manage names/Save names). 


When you first start the Sniffer, it always starts out with its own 
standard defaults. You activate a saved setup by selecting Files, 
then Load, then Setup. When the Sniffer shows you a list of saved 
setup files, select the one you want, and press Enter (Figure 6-4). 
Setup files are identified by the extension, .eNs. The Sniffer sets 
all options the way they were when you saved the setup file. 
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Figure 6-4. List of saved setup files which can be loaded when alternative configurations are 


required. 


Creating a New Startup 
Setup 


You can also save one setup for configuring Sniffer options upon 
startup. In effect, you may override any Network General-defined 
defaults and‘substitute your own. 


To save your own customized startup setup, go to the Files/Save 
submenu, and select Setups. When the window appears for 
entering the file name, type 


STARTUP 


The Sniffer will add the extension, .eNS, for you automatically. 
You must save the new default setup file in the default directory 
at the time the Sniffer is started or in the directory named in set 
ENNAMES (see Appendix B). The next time you start the Sniffer, it 
will read the file and set the configuration accordingly. 
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Managing Names To make its displays more readable, the Sniffer permits you to 
Used in Displays substitute symbolic names for numeric addresses. To translate 
and Filters between addresses and the names that appear in the display, the 


Sniffer refers to a table of name definitions. For each address, the 
table cuntains three columns (see Figures 6-6 and 6-9): 


® Symbolic name. The word or phrase you have assigned to 
the address (blank, when you haven’t assigned one). 


e Address type. The protocol! in which the address can occur. 
Depending upon which protocol interpreters you have 
installed and which are currently available, the types can 
include DLC, XNS, IP, and DRP. 


e Station address. The arbitrary sequence of bytes that 
constitute the address as actually transmitted on the 
network. 


Each time you start the Sniffer, the Sniffer inserts a name for 
itself in the name table. It calls itself “This Sniffer.” (It does that 
even if its station address has some other name in _ the 
STARTUP . END file.) 


A limit of 50 blank names for each address level is imposed on the 
Sniffer when it adds to the name table during capture or display. 
This keeps the table from being filled with entries that have no 
name. If you wish to add a name for an address not in the table, 
you can always enter the address yourself. 


Building the Name Table The working name table is built up in several stages, as follows: 


e Initialization. As soon as you start the Sniffer (even 
before you start capture or display), the Sniffer copies into 
the working name table the contents of the file SraRTUP. END. 


When you ask the Sniffer to Save names, it copies the 
current working name table to the file srarrup.eND. Then 
each time you start the Sniffer, the working name table is 
primed with the names you’ve already established; that 
gives the Sniffer a head start in decoding names. (When the 
names there are no longer appropriate, you can edit them 
individually or clear them all out and start over; see the 
section, “Editing the Name Table.”) 


e During Capture. During capture or playback, the Sniffer 
adds new DLC addresses to the working name table. As it 
appends captured frames to the capture buffer, the Sniffer 
checks each address against its name table. Whenever it 
encounters an address that’s not in the table, it adds an 
entry to the table. The new entry contains the type (DLC) 
and the hexadecimal value of the address, but a blank 
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symbolic name. Both source addresses and destination 
addresses are added in this way. Since some messages are 
addressed to a group or a function rather than to a station 
(for example, to Broudcasé), the table will include the DLC 
address of those functions as well as the DLC addresses of 
stations that transmit. 


During Display. As it displays frames from the capture 
buffer, the Sniffer reviews the addresses it sees in those 
higher-level protocols you’ve checked in the Address level 
option. It adds to the working name table those names it 
has not before encountered. 


The Sniffer adds names in the same way that it adds DLC 
addresses during capture. That is, each name is recorded 
by its type and its numeric value. 


The format in which a higher-level address is displayed is 
controlled by the interpreter for that protocol. Examples are: 


DLC addresses. Present in all frames and shown as 
twelve hexadecimal digits, corresponding to the six-byte 
address. 


XNS addresses. Appears in hexadecimal format and in the 
same way as DLC addresses. 


IP addresses. Represented byte by byte, but each byte is 
represented by its decimal value, a number between 0 and 
255. Successive bytes are separated by a dot, and the whole 
sequence is enclosed in brackets. 


DRP addresses. Addresses in DECnet represented by two 
decimal numbers, the area and the mode numbers, 
separated by a dot. Each number is computed as the binary 
value after masking certain bits in the address. 


Other address levels and formats may be present, depending upon 
the optional protocol suites installed in your Sniffer. 
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Naming Stations 


In general, you manage names by editing the working name table. 
Changes to the name table don’t affect the file staRTUP.END (and, 
hence, don’t last longer than your current work with the Sniffer) 
until you select Save Names, which replaces what’s now in the file 
STARTUP .END with the current working name table. 


When the Sniffer adds a new address to its working name table, 
the symbolic field is initially blank. You can fill in the symbolic 
name by choosing Edit, Resolve names, or Look for names on the 
Manage names menu (These procedures are described in more 
detail in the section, “Editing the Name Table.”): 


Edit. You can manually provide the symbolic name by 
editing the working name table. 


Resolve Names. You ask the Sniffer to search a 
previously-saved name file and copy from it the symbolic 
names it finds there. The Sniffer fills in a symbolic name 
only for an address which is already present in its working 
name table but for which the table lacks a symbolic 
equivalent. 


Look for names. Certain protocols (for example, Novell’s 
or NETBIOS) include provision for stations to exchange 
tables of addresses and the symbolic equivalents currently 
adopted by users of those machines. When you ask the 
Sniffer to Look for names, it scans the capture buffer for all 
such messages in any of the protocols for which it has an 
interpreter. The Sniffer copies to the name table each type- 
and-address pair not already listed there; it does so whether 
or not the frame was actually sent to or from one of those 
addresses. Along with each address, the Sniffer copies its 
symbolic equivalent. For an address already present in its 
working name table, the Sniffer copies a symbolic equivalent 
only when the working name table does not already have 
one. 
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lanage names 





Figure 6-5. Menu options for managing names used in Sniffer displays. 


From the Display option in the main menu, select Manage Names, 
and from there one of the alternatives then displayed (Figure 6-5). 


Editing the Name Table — When you select Edit names, the Sniffer displays the current name 
table (Figure 6-6). One line in the table is highlighted. You can 
scroll through the table to move the highlight, or bring into view 
names that didn’t fit in the window. 





Figure 6-6. Display of the name table. 
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Each name consists of a pairing of name Type (that is, protocol) 
and Address. 


To edit a name, you scroll the EDIT NAMES window until the 
type-and-address pair you want to change is highlighted, and 
there press Enter. The Sniffer opens yet another window in which 
you can write a new symbolic name for that address (Figure 6-7). 





Figure 6-7. Window to provide a new symbolic name for a station. 


When you edit the line headed New Station, the Sniffer asks for a 
station address and a symbolic name; you can enter new stations 
at any selected address level. (You can also reach that window if 
you select New Station when setting a filter on station address.) 
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Figure 6-8. Window to provide an address and a symbolic name for a new station. 


Clearing the Working 
Name Table 


Looking Up Machine 
Names 


Figure 6-8 shows the window for furnishing an address and a 
symbolic name for a new station at the IP address level. 


The option Clear all names empties the Sniffer’s working name 
table, removing both the symbolic equivalents and the addresses. 
Use this when you want to start over, perhaps before resolving 
symbolic names from a .END file or looking for embedded names 
within higher-level protocols in the capture buffer. 


Watch out: Clear all names followed by Save names empties, not 
only the Sniffer’s working name table, but also the name table, 
STARTUP.END, from which names are loaded into the Sniffer 
initially. 


Certain network systems permit machines to assign symbolic 
names to themselves. When you select the option Look for Names, 
the Sniffer searches through frames in the capture buffer in 
search of symbolic names embedded in the transmissions there. It 
looks at all protocol levels for which it has an interpreter. 
However, it substitutes a name it finds only when the working 
name table lacks a symbolic name for that address. When you 
want to know what the stations are (for the moment) calling 
themselves, it’s best to run Look for Names before you start 
assigning names yourself. You can select Clear Names to remove 
all names from the table. 


Names that the Sniffer finds in this fashion may be quite 


transitory. For example, you may find a name that a particular 
user assigned solely for a particular work session. The user may 
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Saving Names 


Resolving Names 
from an External 
Directory 


Building Name 
Dictionaries 


station "All Stanford" 
station "Argus" 
station "awanee" 
station "Backbone A" 
station "Broadcast" 
station "Forsythe" 
station "Frodo" 


station "Kuan" 
station "labrea" 
station "Lindy" 
station "Faquard" 
station "Twodot" 


move to another machine and reassign the same name somewhere 
else. Because such names are so readily changed, you may not 
want to save a name table constructed this way, since it may be 
wrong next time you use it. 


Changes made using the above functions affect the name table in 
memory, which is discarded when you exit from the Sniffer. To 
keep the names, use the Save names command; this copies the 
name table into the file, starrup.END, from which the Sniffer will 
copy names next time you start it. 


To help identify the addresses within a particular trace, you may 
have the Sniffer look up symbolic names from an external 
directory. When you ask it to Resolve names, the Sniffer asks you 
to select from the current directory a file whose extension is . END. 


In the file you have indicated, the Sniffer looks up each type-and- 
address pair in the working name table for which you have not yet 
assigned a symbolic equivalent. It copies the symbolic name for 
that address from the directory file to the corresponding entry in 
the working name table. During the rest of the current work 
session, the Sniffer shows the symbolic name in place of the 
address whenever an address at that level is called for. 


(Note that the working name table is discarded when you exit 
from the Sniffer. However, you may save the current use of 
names by the command Save names. That copies the working 
name table into the file startup.EeND, from which the Sniffer will 
create its initial name table next time you run the Sniffer. 


You may build your own name dictionaries or -eNnD files. The 
Sniffer expects each such file to have the format illustrated in 
Figure 6-9. (That format is the same as the one used in 
STARTUP.END.) You may use a standard text editor (not supplied 
by Network General) to build extra .enpD files of your own or to 
edit STARTUP .END Or HOSTS . END. 


addrtype [36.255.255.255] 
addrtype [36.53.0.10] 
addrtype (36.56.0.208] 
addrtype 020701002BAF 
addrtype FFFFFFFFFFFF 
addrtype (36.54.0.12] 
addrtype AA000301131B 
addrtype 02608C036310 
addrtype (36.8.0.47] 
addrtype (36.54.0.11] 
addrtype O8000AC7CEFE 
addrtype 7.45 


hinbnaoak dan aana 





Figure 6-9. Sample directory of station addresses and symbolic names, to illustrate its 


format. 
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For convenience in subsequent display, the Save names command 
sorts the rows of the table alphabetically by symbolic name. 
However, Resolve names does not require its .END file to be in 
alphabetical order. 


Looking at Figures 6-9 and 6-10, you observe the following: 
e Symbolic name. Enclosed in double quotes. 


e Address type. A specific type (that is, protocol) must be 
assigned for each address. The type can be stated in either 
of two ways: 


p Explicitly for each address, by the phrase addrtype 
"xx" preceding each address (Figure 6-9). You 
substitute the appropriate type for xx. Directories 
generated by Save names show all names in this form. 


> Implicitly, using the current default type (Figure 6- 
10). An address for which no explicit type is shown is 
presumed to belong to the default type. The default 
type is initially "ptc". A line containing only the 
phrase 


addrtype "Xx" 


resets the default type. The new default type remains 
in effect until another line consisting only of addrtype 
and the name of a type. The default type applies to 
any line which doesn’t include its own explicit type. 
Figure 6-10 shows the same information as Figure 6- 
9, but makes use of default types. As the figure 
illustrates, the file may contain redundant blanks (or 
even blank lines). That may help readability. The file 
may contain one-line comments, each set off by a 
leading /* and trailing */. 
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addrtype "DLC" 
station “Backbone A" 
station "Broadcast" 
station "Frodo" 
station "Kuan" 

addrtype "IP" 
station "All Stanford" 
station "Argus" 

/7* Very long name inserted 


ou 


020701002BAF 
FFRFFFFFFFFFF 
AA000301131B 
02608C036310 


[36.255.255.255] 
(36.53.0.10] 


as a test */ 


station "Way down upon dear old Ahwahnee"=[36.56.0.208) 


station "Forsythe" 
station "labrea" 
station "Lindy" 
addrtype "XNS" 
station "Faquard" 
addrtype "DRP" 
station "Twodot" 


[36.54.0.12] 
[36.8.0.47] 

[36.54.0.11] 
O8000AC7CEFE 


7.45 





Figure 6-10. The sample directory of Figure 6-9 rewritten to use default types. 


Station address. May be in one of several forms. The 
specific address types you can use depend upon which 
protocol interpreters are installed on your machine and upon 
which are currently available: 


> 


DLC frames: Hexadecimal format consisting of 
twelve consecutive characters representing the six- 
byte address. 


XNS frames: Appear in hexadecimal format and in 
the same way as DLC addresses. 


IP frames: Decimal format enclosed in brackets. 

There is one number between 0 and 255 for each byte 
of the address with adjacent bytes separated by a dot. 
The number of bytes must be appropriate to the type. 


With the TCP/IP Protocol Interpreter, Network 
General distributes a sample file called nosts.enp. It 
contains a list of commonly-used higher-level 
addresses for the Internet Protocol (IP). 


DRP frames: Represented by two decimal numbers, 
separated by a dot. Each number is computed as the 
binary value after masking certain bits in the address. 


Alphabetization of Station The order in which you write entries in a . ND file doesn’t matter. 


Names 


When the Sniffer builds and displays its working name table, it 
shows the list in alphabetical order by symbolic name. DLC 
addresses which you haven’t named (and which, therefore, have 
blank symbolic names) appear at the top of the display. 
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Each time you edit a name in the working name table, the Sniffer 
re-alphabetizes the list. When you Save names, the resulting file 
STARTUP.END preserves the alphabetization of the working name 
table. 
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Organization of 
Software on the 
Hard Disk 


The Autoexec File 


This section describes the organization of the files on the Sniffer’s 
hard disk. For most purposes, you don’t need to be concerned 
with this information, but for some advanced applications, it’s 
useful to know what goes where. The software on the hard disk is 
organized into the following main directories: 


bos. Contains all the files used by the Sniffer’s operating 
system, other than comMAND.com and the two invisible files 
the operating system uses. 


ENSNIFF. Contains ENSNIFF.EXE, the single program which 
manages all the Sniffer’s activities. This directory contains 
a subdirectory called HELP, containing help files used by 
ENSNIFF, and a NEWPI subdirectory which contains files for 
writing your own protocol interpreters. 


Toots. Contains files used by the selection menu. 


CAPTURE. Contains files and/or subdirectories of captured 
data as you save them from the Sniffer. This directory 
initially incorporates a subdirectory of sample data files 
called sampLes. (You can, if you wish, create additional 
directories for the storage of captured frames; see “Several 
Directories for Capture Files.”) 


The root directory contains the DOS file commanp.com and 
the operating system’s hidden files. It also contains 
AUTOEXEC.BAT, which is executed automatically whenever 
you turn on power or reset the machine by pressing Ctrl-Alt- 
Del, and other batch files used by the selection menu. 


The auToexec.Bat file does the following automatically when the 
machine is started or reset: 


Sets the DOS environment so that DOS can find programs 
in the pos and roots directories and so the Sniffer can find 
its names file and its help file. 


Starts the Sniffer selection menu (see Figure 3-2) by invoking 
the MENU.BaAT file which, in turn, invokes MENUX.EXE. In 
response to your decision, the Sniffer selection menu starts 
the Sniffer from there by invoking ENstaRT with appropriate 
parameters. * 


The parameters are set by the selection menu; you can see what they are by 
displaying the file MENU. TXT. 
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6 Following a normal exit from the Sniffer, you return to the 
Sniffer selection menu. If you there select Return to DOS, 
you return to the root directory. 


The Sniffer program resides in the \ENSNIFF directory, and its help 
files always reside in \ENSNIFF\HELP. 


ENSTART.BAT, the batch file that starts the Sniffer, sets the current 
directory to \capturE. The Sniffer uses the current directory for 
three things: 


@ The initial directory in which to store files of captured 
frames from the capture buffer. 


e The initial directory in which to look for stored files of 
captured frames and from which to load them to the capture 
buffer for analysis. 


e The default directory in which to look for the names file, 
called STARTUP.END. The names file specifies the characters 
to appear in displays to replace or to augment the station 
addresses that the frames actually contain. 


To keep separate various sets of captured data (for example, data 
collected from different networks or under different 
circumstances), you may want to set up different directories to 
contain the files. The batch file that starts the Sniffer ordinarily 
makes \CAPTURE the current directory. 


When youw’re about to save some files, you may wish to create a 
new directory to contain them. You can do that without leaving 
the Sniffer. On the Files menu, select Make Directory. When 
prompted, type the name of the new directory. 
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Figure 6-11. The Make Directory window for entering a new directory path name. 


Setting a Path toa 
Different Directory 


DOS interprets the name you write with respect to the current 
directory. For example, if your current directory is \CAPTURE\ and 
you ask for a directory called pata, the Sniffer passes your request 
to DOS, and DOS creates a directory whose full name is 
\CAPTURE\DATA. DATA is a subdirectory of \CAPTURE\. 


When you don’t want the new directory to be a subdirectory of the 
current one, write its complete path, and make the first character 
\ to show that the path you’re writing starts from the root 
directory. 


Creating a new directory does not of itself cause files to be saved 
into it. The Sniffer just creates it. If you also want to use the 
new directory as the default, use Files/Change path to indicate 
that. 


When the files you want to work with are in a directory different 
from the current directory (i.e., different from the directory from 
which you started the Sniffer), you can establish a path to the 
directory you want. You do that by the following steps: 


e Return to the Files menu. 
& Select Change path. 
e Type the complete path to the directory in which you want 


the Sniffer to look for files to load and to store files that you 
save. 
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Figure 6-12. The Change Path window for switching the directory path used for saving and 
loading data and setup files. 


Switching to Another 
Directory from within a 
List of Files 


The Files/Change path option, in effect, supplies an automatic 
prefix to any file names that you use. For example, if the current 
directory is \CAPTURE\, and if you specify the prefix para, the 
Sniffer loads or saves files in \CAPTURE\DATA. 


However, if you backspace over the current directory and then 
enter a prefix which starts with a slash (for example, \patTa) the 
leading slash indicates that you’re not just tacking on an 
amendment to the DOS default directory, but providing an entirely 
new path. In that case, the Sniffer ignores the DOS current 
directory and uses the path you’ve written instead. 


To make the Sniffer start automatically in a directory other than 
\CAPTURE, edit the ENSTART.BaT file, substituting the appropriate 
directory name for \CAPTURE in the command CD \CAPTURE. 


Note: By providing a path for the Sniffer when it saves or loads 
capture files, you do not change the DOS “current directory,” and 
you do not change where the Sniffer looks for a names file. 


Some of the entries in the LOAD DATA FROM and the CAPTURE 
DATA FROM windows (see Figures 4-14 and 6-2) may be 
directories rather than files. When you highlight a line that 
represents a directory and press Enter, the Sniffer changes the 
display to show a list of the files in that directory. The notation 

. <DIR> in the top row indicates the directory one step nearer the 
root directory; in this case, you might select it to move from the 
directory called caprurE to the root directory. 
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Several Names Files 


Selecting a directory line in the files display has the same effect as 
changing the path. 


The Sniffer’s display routines refer to the file starTup.END to find 
names to replace or to augment the hardware addresses it finds in 
the frames it displays. To find startup.enp, the Sniffer program 
first looks in the current directory. If it doesn’t find a name file 
there, it consults the environment string for the name of a 
directory in which to look next. In the autoexec file, the 
environment string is set by the command 


SET ENNAMES = \ENSNIFF 


When you have several different directories of saved capture files, 
each directory may (if you wish) have its own STARTUP.END. For a 
directory that does not contain its own names file, the program 
looks for a names file in the directory specified by the SET ENNAMES 
command. ' 
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Appendix A. Format of Saved Data Files 


* 


For some purposes of data analysis, it may be useful to write a 
program which reads the saved trace data files. This appendix 
describes the format of those files. Note, however, that in many 
cases it will be easier to have the program read the formatted file 
produced by “printing” one of the display formats tw a file, 
particularly if you choose the option to omit page titles. 


The data files saved by the Sniffer consist of sequences of variable 
length binary records. Since all 256 possible byte values are 
possible within the data, the file may not be edited by an ordinary 
text editor. 


The first sequence of bytes in a data file is a text message saying 
that the file contains Sniffer data.* The message ends with an 
endfile character (0x1a, Ctr1-z). This has been done so that even 
if you accidentally type the file to the screen, or otherwise treat it 
as a text file, the display reaches a terminator before reaching 
unprintable characters that may be in the data. 


All multibyte arithmetic fields (computed by the Sniffer during 


capture) are stored with the least significant byte first. Frame 
data are stored in the byte order transmitted. 


For historical reasons, the message in all such files is “TRSNIFF data,” 
regardless of the network or the type of Sniffer. 
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Header 


Following the text message string, the file contains an arbitrary 


number of variable-length records, each of which begins with the 
following header: 


struct f_rec_struct { 
int type 
int length; 


int rsvd; 


Standard record header. 
Type of this record. 
Length of remainder of this record. 


Reserved word, currently 0. 


}; The first field of the record header indicates what type of record 
data follows, and currently can have the following values: 


#define REC_VERS1 
#define REC_FRAME2 4 


#define REC_EOF 3 


Version record (£_vers). 
Frame data (£_frame2). 


Endfile record (no data follows). 


Other types are reserved for future use. 


Structures within the 
Data File 


The data file consists of a single version record, a series of frame 
data records, and a single endfile record. 


The format of the data part of these records follows. 


Version Record 


struct f_vers_struct { 
int maj_vers; 

int min_vers; 

struct date_struct date 
char type; 

char network; 

char format; 

char timeunit; 


int rsvd[{3]; 
}; 
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Major version of Sniffer. 

Minor version of Sniffer. 

Date & time (4 bytes, DOS format) 

What type of records follow. 

An indicator of the network type. 

What format version this is. 

An indicator of the frame timestamp unit. 


Reserved words. 
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Frame data records. 


struct f_frame2_struct { 
int time_low; 
int time_mid; 
int time_high; 


int size; 


char fs; 
char flags; 


int true_size; 


int rsvd3; 


i 
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Low time in 0.838096 usec units. 
Mid time in 54.9255 msec units. 
High time in hours. 


Number of bytes actually written in this file (may be 
less than the original length of the frame). 


Frame error status bits. 
Buffer flags - for internal use. 


If non-zero, the size of the original frame (since not all 
the data was recorded). 


Reserved; currently 0. 


The frame data follows. 


Endfile Record The endfile record has no data; it consists only of the record 


header. 


There is no explicit encoding of the length of the file 


except as part of the file’s directory entry. 
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Appendix B. File Name Conventions 


ENSNIFF.EXE File 


STARTUP.END File 


STARTUP.ENS File 


ENSNIFF.HLP File 


-ENC Files 


-ENS Files 


-PRN Files 


-END Files 


The Sniffer’s executable code is named ENSNIFF.EXE. If you have 
not changed any of the batch files, \caprure is the current 
directory while the Sniffer is running. 


At startup, the Sniffer initializes its name table by reading the file 
STARTUP.END. You can update this file by saving the current name 
table, but you do not control the name of the file. The names table 
should either reside in the current directory, or else in a directory 
locatable by including in the Sniffer’s auroexec.sar file or the 
batch file that starts the Sniffer the DOS command SET ENNAMES = 
path. 


The default settings of the Sniffer are in the file STARTUP.ENS. 
You can customize these settings. See the instructions in Chapter 
6, “Creating a New Startup Setup.” 


When you press F1 to request help during execution, the Sniffer 
refers to the file ENSNIFF.HLP. This help index file should reside 
either in the current directory or else in a directory locatable by 
including in the Sniffer’s aurozxec.sat file or the batch file that 
starts the Sniffer the DOS command, SET ENHELP = path. The 
help index file itself contains the names of the individual help files, 
normally located in the directory \ENSNIFF\HELP. 


You can save the capture buffer to a file that you name. The 
Sniffer accepts only a name without an extension, and supplies the 
extension .ENC for each such file. To load the capture buffer, you 
must select from a list the Sniffer displays; it considers only files 
with the extension .ENC. 


You can save a record of the settings of all menu options to a file 
that you name. The Sniffer accepts only a name without an 
extension, and supplies the extension .eNs for each such file. To 
load the setup file, you must select from a list the Sniffer displays; 
it considers only files with the extension .ENS. 


You may direct a printed record of the capture buffer to a file that 
you name. The Sniffer prompts for a name without an extension, 
and provides the extension .PRN. 


When you ask the Sniffer to Resolve names and to look up 
symbolic names in an external dictionary, you select a file from a 
list the Sniffer displays. The Sniffer considers only files with the 
extension .END. 
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Type Name Location 

Help directory ENSNIFF.HLP Current, or SET ENHELP 
Initial name table STARTUP.END Current, or SET ENNAMES 
Initial setups STARTUP.ENS Current, or SET ENNAMES 


Captured frames * J ENC Anywhere 
Menu setups * ENS Anywhere 
Print files * PRN Anywhere 
Name dictionary * , END Anywhere 





Table B-1. File extensions and locations summary. 
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Appendix C. Extending 
Sniffer Protocol Interpreters 


Overview 


What Does a Protocol 
Interpreter Do? 


This appendix describes the rules and conventions for writing 
programs that extend the Sniffer’s ability to interpret protocols. 
To make use of this Appendix, you need to be familiar with: 


e The general operation of the Sniffer. 


e The general structure of network frames and the detailed 
structure of the protocol to be interpreted. 


° The C programming language and the MSDOS 
programming environment. 


Network General is constantly expanding its suite of optional 
Protocol Interpreters. Before writing your own, check with us 
to see what is currently available. In addition, several of the 
existing interpreters have “stub routines” which are called when 
opcodes or type fields are encountered for which we have no 
information. When you are are using a protocol which is an 
extension to an existing protocol, it is much easier to replace or 
modify the stub routine than to write a new Protocol Interpreter. 


A Protocol Interpreter (“PI”) is a routine (or set of routines) which, 
when invoked, receives a pvinter to data sumewhere within a 
frame. The interpreter has four tasks: 


® To generate one or more short text lines for its protocol level 
to be displayed in the Summary window. 


e To generate lines for the Detail window. 
e Call the Protocol Interpreters for embedded protocols, if any. 


e Optionally, supply new symbolic names discovered within 
the protocol data. 


There are two types of Protocol Interpreters: demultiplexed and 
embedded. A demultiplexed PI is called directly from the Sniffer, 
based on the frame’s 802.2 LLC DSAP or Ethertype. An 
embedded PI is called from within another PI to interpret a 
protocol nested at a higher level. 


An embedded PI may be shared; that is, a PI may be called from 


several other Pls and thus may be used at different protocol 
levels. 
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Calling Conventions for 
Protocol Interpreters 
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Suppose you write a Protocol Interpreter function named new_pi. 
It is called from the Sniffer as follows: 


int new_pi (frame_ptr, frame_length) 


char *frame_ptr; 


int frame_length; 


char *d1lc_header; 


char *llc_header; 


Pointer to frame data 


The length of the frame data starting at frame_ptr 


The pointer to the frame data starts within the physical frame at 
the beginning of the data for the protocol. Thus it skips previous 
protocol fields, including source and destination addresses, type 
fields, and any previously-embedded protocol data. 


The Sniffer permits the operator to request that the Sniffer 
truncate frames as it captures them. Then the Sniffer records no 
more than a certain number of bytes for each frame and discards 
the rest. When the operator has elected truncation, frame_length 
is the length of the stored (truncated) data, and the global integer 
bytes_not_present indicates how much additional frame data was 
received but not recorded. 


For a demultiplexed PI called for a particular LLC DSAP, 
frame_ptr is the address of the first byte of the information field; 
the information field immediately follows the source and 
destination SAPs and the control field. The SAP Protocol 
interpreter is called for any frame with an information field, such 
as I, UI, XID, TEST, or FRMR. It is not called for frames which do 
not contain information, such as RR. 


For a demultiplexed PJ called for a particular Ethertype, 
frame_ptr is the address of the first byte of the information field; 
the information field immediately follows the 2-byte Ethertype. 


A PI’s return value is the number of bytes of frame data that it 
interpreted. The calling interpreter may use the return value to 
decide whether any subsequent interpreters are to be called. If 
there is no more data left to interpret, simply return the initial 
value of frame_length. (Note that some of the earlier PIs do not 
follow this convention.) 


If the Protocol Interpreter needs access to DLC or LLC header 
fields, or to the frame number, it may refer to the values of the 
following global static variables: 


Pointer to DLC header starting with the first byte of the 
frame. 


For 802.3 networks, a pointer to the LLC header of the 
frame, starting with the DSAP field. 
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int llc_type; 

int pi_frame; 
Registering Protocol 
Interpreters 


struct pi_data 


char *menu_title; 


int 


int 


int 


pi_type; 


ntypes; 


*types; 


*new_pi(); 
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For 802.3 networks, the type of the LLC frame; see the 
LLC_xxx macros in pi.h. 


The current frame number. 


A protocol interpreter for an embedded protocol should be invoked 
using the same calling convention, although it is possible to include 
additional parameters if necessary. 


Each protocol interpreter should be registered before it is called. 
Registration is required for a demultiplexed PI, so that the Sniffer 
knows about it. For an embedded PI, registration is optional. 
When you have registered an embedded protocol, its name appears 
in the display filter menu, so the operator can select frames that 
contain your protocol. 


All registration occurs in the function initpi.c, called when the 
Sniffer is initialized. Registering a Protocol Interpreter generates 
a pointer to a structure which holds data relevant to the 
interpreter. That pointer must be supplied in subsequent calls 
that generate screen output. The pointer should be saved in a 
static variable known to the interpreter. 


The function which registers a Protocol Interpreter has the 
following calling sequence: 


*register_pi (menu_title, pi_type, ntypes, types, new_pi, prefix) 


A pointer to the string that will appear in the menu as a 
selectable item and which the operator can use to control 
whether Summary lines for that protocol are displayed. 
The string is also used in constructing the message 
which appears at the bottom of the menu window. The 
string should not exceed 18 characters. 


The type of Protocol Interpreter; see the PITYPE_xxx 
symbols pi.h. The most common values are PITYPE_SAP 
for a SAP-demultiplexed PI, pirypE_ETYPE for an 
Ethertype-demultiplexed PI, and p1ITYPE_EMBEDDED for an 
embedded protocol interpreter called by another. 


The number of DSAPs or Ethertypes that. can be 
processed by this demultiplexed interpreter. For an 
embedded protocol, specify 0. 


An array of “ntypes” integers representing the DSAPs 
or Ethertypes that can be processed by this 
demultiplexed interpreter. For an embedded protocol, 
this parameter is ignored and should be specified as a 
null address. 


The address of the Protocol Interpreter function which is 
called as previously described. 
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char *prefix; 


The Protocol Interpreter 


Data Structure 


struct pi_data { 


int 
int 
int 
int 


int 


do_sum; 
do_int; 
do_count; 
do_names; 


recursive; 


Generating Output from 
Protocol Interpreters 


A pointer to a string containing an abbreviation 
identifying this PI. It appears as a prefix for lines in the 
Detail window. To preserve alignment with displays 
produced by the Sniffer’s other Protocol Interpreters, the 
string should be in the form "xxx: "; that is, five 
characters, the last two of which are colon and blank. 


This structure is allocated, and a pointer to it returned, by the 
register_pi() function. Only the fields described below are 
relevant to Protocol Interpreters. They are booleans which 
indicate what functions are required. The integer booleans, in 
standard C fashion, are 0 if false and non-zero if true. The 
declaration for this structure is part of the file pi.h. 


Boolean: 
Boolean: 
Boolean: 
Boolean: 


Boolean: 


frame? 


generate Summary lines? 
generate interpretation lines? 
only count Summary lines? 
add symbolic station names? 


recursive call to get information for another 


If do_sum is true, you are to generate a Summary line. If do_count 
is also true, then only a count of Summary lines is really needed, 
so for added efficiency you may optionally allocate the Summary 
line buffer but omit actually generating the text. 


If do_int is true, you are to generate one or more Detail 
interpretation lines. The operator cannot elect options that would 
make the do_sum and do_int flags true at the same time. 


If do_names is true, the operator has selected the Search for names 
menu option. Examine the frame data for embedded station 
names defined by the protocol. If any are found, call the 
add_station_name() function, described later, to enter the names 


into the name table. 


If recursive is true, this is a call from another Protocol 
Interpreter, seeking information about some other frame. If you 
do not have the required information, do nothing except call any 
more deeply-embedded protocol interpreters that you know about. 


(See the section, 


“Advanced Topic: Dependencies on Other 


Frames,” for more information.) 


Regardless of how the flags are set, always call the corresponding 
PI for each protocol embedded in the current one. 


To generate a line for the Summary window from within a Protocol 
Interpreter, first get the address of a line buffer by calling 


get_sum_line(): 
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char *get_sum_line (pid) Returns a pointer to the line buffer 
struct pi_data *pid; The value returned when the interpreter was registered 


Then move a character string (ending with a null) into the buffer 
provided. The length of the string including the null cannot exceed 
MAX_SUM_LINE. (For visual consistency of the displayed output, the 
string should begin with a 3-character identification of the protocol 
layer, a colon and a blank.) 


Generating a line for the Detail window is similar. However, the 
function to get the address of a line buffer also provides an 
optional offset and length that show where in the frame the 
information was found. This is used to highlight the hex field 
when the operator selects the corresponding line of the Detail view. 


char *get_int_line (pid, offset, length) 

Returns a pointer to the line buffer 
struct pi_data *pid; The value returned when the interpreter was registered. 
int offset; The offset from the DLC header of the field which 


generated the interpretation line. 
int length; The length of the field, or 0 if no highlighting is desired. 


The string should be built in the supplied buffer. Its length, 
including the final null, must not exceed MAX_INT_LINE. 


In general, the Sniffer automatically scrolls the Detail window so 
that the top line is the first line for the protocol that the operator 
selected in the Summary window. If you wish some other line of 
your protocol’s Detail lines to scroll to the top, you may so indicate 
by using a negative offset when you call get_int_line for that 
line. 


Generate Summary or Detail display lines only when the 
appropriate boolean in the pi_data structure is true. Regardless 
of how the flags are set, always call the PIs for any protocols 
embedded in the current one. 


Adding Symbolic Names When you call your Protocol Interpreter and do_names is true, 

to the Name Table you must examine the frame for an embedded name, and (if 
you find one) add it and its symbolic equivalent to the station 
name table. When you discover a useful name, call the function 
add_station_name, as follows: 


add_station_name (flagstype, length, addr, name) 


int flagstype; The type of the address plus option flags; see pi.h for 
definitions. Example: ADDRTYPE_DLC + ASN_NOREPL 
indicates that the address is a datalink-level address and 
that its symbolic name is not to replace a symbulic 
equivalent already assigned to that address in the name 
table. 
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int 


char 


char 


length; 


*address; 


*name; 


Declaring Embedded 


Addresses 


The length of the address, from 1 to 16 bytes. Example: 
6 for datalink addresses. 


A pointer to the binary station address for this name. 


A pointer to the ASCII name to enter in the table; 1 to 
31 characters (including a final NUL). 


Since names discovered in the protocol data may be transitory, it 
is probably best to use ASN_NOREPL. That way, when the file 
startup.trd already supplied a symbolic equivalent for the 
address, the name you find dues not replace it. 


Each frame has two DLC-level addresses associated with it by the 
Sniffer. If a protocol interpreter knows of other kinds of addresses 
that are associated with this frame, such as Internet addresses 
embedded within the frame data, it may announce those addresses 
by calling the following routine: 


add_frame_addr (flagstype, length, addr) 


int 


int 


int 


flagstype; 


length; 


*address; 


Displaying Symbolic 


Names 


char *format_addr 


char 


int 


char 


int 


*line; 


length; 


*address; 


flagstype; 


The type of the address plus AFA_xxx option flags; see 
pi-h for definitions. Example: ADDRTYPE_IP + AFA_SRC 
for a TCP/IP internet source address of this frame. 


The length of the address, from 1 to 16 bytes. Example: 
4 for TCP/IP internet addresses. 


A pointer to the binary station address to be added. 


If you wish to include the symbolic name corresponding to an 
address at any level in the text of a Summary or Detail line, you 
may use the following routine to look up and format names from 
the current names table: 


(line, length, addr, flagstype) 


The address of a character buffer into which the 
formatted name is placed. 


The length of the address, from 1 to 16 bytes. Example: 
6 for DLC-level addresses. 


A pointer to the binary station address to be looked up in 
the names table. 


The type of the address plus FmT_xxx option flags; see 
pi-h for definitions. Example: ADDRTYPE_DLC + 
FMT_BOTH for a DLC address to be formatted with both 
the hex value and the symbolic name. 
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If you want to create special flags and to have the Sniffer flag 
frames and post the flags in the Summary view, you can call the 
following function: 


void add_frame_flags(str) 
char *str; /* characters to add to the flags */ 


Using Other Protocol 
Interpreters 


At most, six flag characters will be displayed for each frame. (See 
the section, “Flags Option,” in chapter 5.) 


In most cases, the Protocol Interpreter that you write will be at 
the top of an already-interpreted protocol stack, and the only other 
PIs you call will be your own. You may, however, also call 
existing PIs if the protocol they interpret is embedded within 
yours. See the initpi.c file for a complete list. of the PIs which 
are available, ‘but remember that only those which are part of the 
installed Protocol Suites will be in your library. Also note that 
new Protocol Interpreters are constantly being added; contact the 
factory for the latest list and announcements of new Suites. 


The mechanisms by which Protocol Interpreters decide what other 
PIs to call are varied. The best protocols, from the PI writer’s 
point of view, are those that contain a universally-assigned 
identifier—such as a well-known port number—which indicates 
what protocol is at the next level. Without such an identifier, the 
Pl must rely on other context, sometimes from previous frames, to 
determine what the protocol stack is for each frame. The Pls 
which come with the Sniffer use a variety of techniques, from 
maintaining session-connection tables across many frames to 
heuristic identification of likely candidate protocols. A complete 
description of these techniques is beyond the scope of this manual. 


The resulting dynamic nesting of PIs can be complex, and a given 
PI may be called from several alternative protocol stacks. The 
following diagram shows the structure of a few of the PIs. Note 
that the interp_smb interpreter for PC LAN Program SMBs 
occurs in several places. 
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interp_dlc 


IF 802.2 network THEN 
IF SSAP == DSAP = OxFF THEN 
interp_xns (Novell) 
interp_smb 
interp_smb_other 


ELSE interp_llc 
SWITCH on DSAP 


SAP AA: interp_snap 
IF vendor == 0 THEN {same as ETHERTYPE below} 


SAP FE: interp_isonw 
interp_isotp 
interp_smb 
interp_smb_other 


ELSE IF Ethernet/Ethertype network THEN 
SWITCH on ETHERTYPE 


0200: interp_pup 


0600, 0807: interp_xns 
interp_smb 
interp_smb_other 
0800: interp_ip 
SWITCH on protocol 
1: interp_icmp 
6: interp_tcp 
SWITCH on port 
21: interp_ftp 
23: interp_telnet 
25: interp_smtp 
17: interp_udp 
SWITCH on port 
53: interp_domain 
111: interp_rpe (Sun) 
2049: interp_rpc (Sun) 
SWITCH on program number 
100000: interp_pmap 
100003: interp_nfs 
100004: interp_yp 
100005: interp_mount 


0806, 8035: interp_arp 


6001: interp_decmopdl 

6002: interp_decmoprc 

6003: interp_decdrp 

interp_decnsp 

interp_decdap 
interp_decscp 
interp_decnice 

6004: interp_declat 


9000: interp_loop 


9002: interp_bridge 
This shows only a subset of the PIs and how they are interrelated; 
the true structure is considerably more complex. 


Some of the existing Protocol Interpreters call null stubs to process 
command codes or types that they do not recognize. By replacing 
or modifying those stubs (whose C-language source is supplied), 
you can extend those interpreters without rewriting them. 


Currently both the NETBIOS and the SMB interpreters do this; 
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Advanced Topic: 
Dependencies on Other 


Frames 


int 


int 


char 


char 


char 


they call interp_netbios_other() and interp_smb_other(), 
respectively, to process unknown message types. The calling 
convention is the same as for registered PIs. In fact, you may, if 
you wish, register your extension of those stubs su that they can 
be independently selected as a display filter. 


Another approach to extending existing PIs, when there is no stub 
routine or it is not called at the right time, is to write a new PI 
which acts as a prefilter to the existing PI. In this case you can 
piggyback on the existing registration of the PI by changing the 
name of the function in the module initpi.c to be the name of 
your new routine. When your routine gets control, it looks at the 
frame data passed to it to see if it is the extension to the protocol 
which it knows how to handle. If so, it interprets the data and 
returns. If not, it calls the existing PI under its original name. 


Note that to use any of these extension techniques, it is not 
necessary to have the source code for the existing Pls. 


In cases where the interpretation of a frame must depend on 
information in prior frames, there are three mechanisms 
available. In increasing order of complexity they are: 


e The PI can cache any information that will be useful for 
subsequent frame interpretation in private static variables. 
Beware, however, that the PI may be called to interpret 
frames in any order. The cache, therefore, will only 
sometimes be valid. 


In order to recognize that cached data is invalid when new 
frames have been loaded or captured, the PI can examine 
the global integer variable data_version, which is 
incremented each time new data is present. 


This is the easiest and most efficient of these frame 
dependency mechanisms; in many cases it is sufficient. 


e The PI can get access to the data in other frames by calling 


the following routine: 


pi_get_frame (frame_num, p_dlc, p_llc, p data) 


The number of the frame you want. The first frame is 
frame number 0. 


The address of the pointer that the function will set to 
the start of the DLC header. 


The address of the pointer that the function will set to 
the start of the LLC header for Tuken-Ring networks. 


The address of the pointer that the function will set to 
the start of the data following the LLC header for 
Token-Ring networks. 
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int 


int 


The function’s return value is the size of the frame, provided 
the length is available. The return is zero when the frame 
does not exist. 


Note that this technique requires the PI to know the position 
of the data relevant to it, stated as the offset from the start 
of the data portion of the frame. This means that the PI for 
an embedded protocol must take into account the structure 
of the protocol in which it is embedded. 


The PI can request that the protocol interpreters be invoked 
for previous frames by calling the following routine: 


pi_invoke_pis (frame_num) 


frame_num; 


The desired frame number. The first frame is frame 
number 0. 


The return value is non-zero when the frame number is 
valid and the protocol interpreter is successfully called. 


In general this causes protocol interpreters to be invoked 
recursively. They are informed that this is a recursive 
invocation by the recursive flag in their data structure. If 
they have information which is needed by the originating 
interpreter, information may be exchanged by using static 
shared variables. For example, the recursively invoked 
interpreter might check whether it is the request frame for 
the currently active response, and if so indicate what the 
original request was. 


A useful technique for increasing efficiency when frames 
must be recursively examined is to completely scan all 
frames once when new data is captured or loaded, rather 
than to search back each time a frame is interpreted. As 
the scan proceeds you can keep information from earlier 
frames (such as connection identifiers and port numbers) in 
a temporary table, and refer to that information to 
determine how to interpret other frames. 


As a result of the complete scan you can save what is 
needed for subsequent interpretation of each frame ina 
private static data area; this can often be a simple "protocol 
type" byte. If the data needed for each frame is small, you 
may use a storage area provided for each frame. When you 
are called to interpret a frame, the variable pi_frame_data 
(declared in pi.h) will point to an area of 
PI_FRAME_DATA_SIZE bytes (currently 3) which is unique to 
each frame. 


Special care must. be taken if it is possible that more than 
one interpreter in the protocol stack for a single frame might 
be making recursive calls. First, the interpreters must 
agree by convention about the use of the pi_frame_data 
storage area. Second, each interpreter must distinquish its 
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recursive calls from those of other interpreters. 


The following code fragment shows the structure of an 
intepreter which does an initial frame scan, uses the 
frame_data area, but can otherwise coexist with other 
interpreters that do recursive calls: 


interp_xxx (pointer, length) 
char *pointer; 
unsigned length; 


static int old_data_version = -1; 
static boolean our_scan = FALSE; 


if (!pi_data_xxx->recursive 
&& data_version != old_data_version) { /* do our scan */ 
int frame; 


our_scan = TRUE; 
old_data_version = data_version; 
frame = 0; 

while (pi_invoke_pis (frame++) ) 


, 
our_scan = FALSE; 


else if (our_scan) { 7* we have been called during the scan */ 
/* compute what will be needed to display this frame */ 
*pi_frame_data = ....; 7* store it in the frame_data area */ 


if (pi_data_xxx->do_sum) { 
/7* generate a summary line */ 


if (pi_data_xxx->do_int) { 
/7* generate detail lines */ 


/* call embedded protocol intepreters here... */ 
interp_yyy (..-); 


return length; 


} 


This is the least efficient of the three mechanisms, but it is 
the most general and is entirely independent of earlier 
protocol headers. This is especially important when writing 
embedded PIs that may be invoked from more than one 
protocol stack or when earlier headers are variable in size. 


Debugging Messages To write a debugging message from within a protocol interpreter, 
use the function debug_msg ("Message of up to 100 
characters", optional_variables). It is similar to printf) in 
that the string to control formatting may apply to variables 
included as the subsequent arguments. While it is running, the 
Sniffer saves the last 100 such messages in a scrollable window 
which can be made visible by pressing Shift-F1 and closed using 
the Esc key. 
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Advanced Topic: 
Using the PIF Formatting 
Routines 


Protocol interpreters may be written with the use of no additional 
functions other than those already described and those available in 
the standard C library. For fixed-format data, the simplest 
approach is often to write structure declarations and simply 
format Summary and Detail lines using the standard sprint£() 
library function. 


When the data contains many variable-length or optional fields, 
however, using C-language structures becomes quite awkward. 
To address this problem, we provide a series of stream-oriented 
formatting utilities called PIF (“Protocol Interpreter Formatting”) 
routines. The use of PIF routines is entirely optional; you may 
write interpreters without them if you choose. 


A Protocol Interpreter that wishes to use the PII routines makes 
one call to the initialization function pif_init() each time it is 
called for a new frame. The PIF routines then maintain an offset 
into the frame data, called the “PIF offset,” which is used to 
extract data in various forms. There are three general classes of 
routines: 


e Routines that return a data item to the caller begin with 
pif_get_. The PIF offset is not updated. These routines 
may be used to extract data for either the Summary line or 
the Detail window. 


9 Routines that display a data item on a line in the Detail 
window begin with pif_show_. The PIF offset is 
incremented by the length of the data item and thus points 
to the next item. 


e Other miscellaneous PIF functions. 
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The PIF Routines 


pif_init 
pif_save 
pif_restore 


pif_get_byte 
pif_get_word 
pif_get_word_hl 
pif_get_long 
pif_get_long_hl 
pif_get_ascii 
pif_get_ebcdic 
pif_get_lstring 
pif_get_addr 


pif_show_byte 
pif_show_word 
pif_show_word_hl 
pif_show_long 
pif_show_long_hl 
pif_show_2byte 
pif_show_4byte 
pif_show_6byte 
pif_show_nbytes_hex 


pif_show_ascii 
pif_show_ebcdic 
pif_show_lstring 


pif_show_flag 
pif_show_flagbit 
pif_show_flagmask 
pif_show_date 


pif_show_space 
pif_header 
pif_trailer 
pif_autoscroll 
pif_line 
pif_set 
pif_skip 
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Table C-1 presents a summary of the PIF routines that are 
available. All three categories presented above are represented. 


Initialize PIF global variables. 
Save PIF info before calling an embedded PI. 
Restore PIF info after calling an embedded PI. 


Get value of a single byte. 

Get value of 2-byte word in low-high order. 
Get value of 2-byte word in high-low order. 
Get value of 4-byte longword in low-high order. 
Get value of 4-byte longword in high-low order. 
Get ASCII characters into a C string. 

Get EBCDIC characters into a C string. 

Get a length/string into a C string. 

Get the address of the current field. 


Display a single byte. 

Display 2-byte word in low-high order. 
Display 2-byte word in high-low order. 
Display 4-byte longword in low-high order. 
Display 4-byte longword in high-low order. 
Display 2 one-byte fields. 

Display 4 one-byte fields. 

Display 6 one-byte fields. 

Display an n-byte field in hexadecimal 


Display a string of ASCII characters. 
Display a string of EBCDIC characters. 
Display a length/string of ASCII characters 


Initialize to display bits of a flag byte. 
Display flag bit values. 

Display flag bit value if it matches the mask. 
Display a date and a time. 


Display a blank line 

Display a Detail window header message. 

Display a Detail window trailer message. 

Set Detail window autoscroll point to be the next header. 
Return a Detail window line buffer and advance the pointer. 
Set current buffer pointer. 

Move current buffer pointer backwards or forwards. 


Table C-1. Summary of PIF routines. 


Below are detailed descriptions of each of the calling sequences 
presented in Table C-1. 


void pif_init (pi, p, len) /* Initialize PIF globals */ 
struct pi_data *pi; /7* Protocol Interpreter’s control block ptr */ 
char *p; /7* Start of frame data to interpret */ 
int len; /7* Length of frame data */ 


Initialize the PIF variables. P1IF_INIT must be called by the PI routine before 
any other P1IF_xxx routines can be used. 
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void pif_save (pd) 7* save pif variables */ 
struct pif_info *pd; /7* Ptr to area used to save pif state */ 


Save the PIF variables before calling an embedded PI. The caller supplies a 
“pif_info” area (defined in pi-h) into which the current state information is 
saved. The pif_restore routine can be used to restore the state information. 
This should be used before calling an embedded Protocol Interpreter that uses 
the PIF routines if you wish to use the PIF routines after it returns. 


void pif_restore (pd) /7* restore pif variables */ 
struct pif_info *pd; /7* Ptr to area used to restore pif state */ 


Restore the PIF variables. The caller supplied a pif_info” area which was 
previously supplied to pif_save. 


char pif_get_byte (delta) 
int pif_get_word (delta) 
int pif_get_word_hl (delta) 
long pif_get_long (delta) 
long pif_get_long_hl (delta) 


int delta; 


Fetch a byte, word (2 bytes) or longword (4 bytes) from the frame data at the 
current PIF offset plus the (signed) value of delta. The PIF offset is not 
changed. The “hl” versions are for multibyte fields stored with the most 
significant byte first. These are macros defined in pi.h. 


char *pif_get_ascii (offset, len, result_str) /* get asciiz string */ 
int offset; /7* offset to string from current pif pointer */ 
int len; 7* maximum number of source bytes */ 
char result_str[]; 7* destination string */ 


Move a printable ASCIIz string at the current offset in the packet to a C string. 
Unprintable characters are replaced with the character “.”. The destination 
string ends with a “\o” even when the source doesn’t. The return value is a 
pointer to the end (null) of the destination string. The PIF offset is not 
changed. 


char *pif_get_ebcdic (offset, len, result_str) 7* Get ebcdic string */ 


int offset; /7* offset to string from current pif pointer*/ 
int len; /7* maximum number of source bytes */ 
char result_str[]; /* Gestination string */ 


Translate a printable EBCDICz string at the current offset in the packet into 
ASCII and move it to a C string. Unprintable characters are replaced with the 
character “.”. The destination string ends with a “\o” even when the source 
doesn’t. The return value is a pointer to the end (null) of the destination string. 
The PIF offset is not changed. If the menus force ASCII display, this calls 


pif_get_ascii instead. 
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char *pif_get_lstring (offset, result_str) 7* Get Lstring 
int offset; 7* Signed offset from current position 
char result_str[]; /7* Return ASCIIz string here 


Move an ASCIIz Istring from the current offset in the packet to a C string. An 
“Istring” starts with a length byte followed by that number of characters. 
Unprintable characters are replaced with the character “.”. The destination 
string ends with a “\o” even when the source doesn’t. The return value is a 


pointer to the end (null) of the destination string. 


char *pif_get_addr () 7* veturn the data address 


Return the address of the field which is at the current PIF offset. This is a 
macro defined in pi.h. 


char pif_show_byte (prstr) 
int pif_show_word (prstr) 
int pif_show_word_hl( prstr) 
long pif_show_long (prstr) 
long pif_show_long_hl (prstr) 
void pif_show_2byte (prstr) 


void pif_show_4byte (prstr) 


void pif_show_6byte (prstr) 


void pif_show_nbytes_hex (prstr, n) 
char *prstr; /7* A sprintf() control string 


Create a new line in the Detail window with the text given in prstr and the 
indicated data from the frame. The text should contain a formatting code like 
%d or %x indicating where the value should be printed. For the longword 
displays, the formatting code should be %14 or %1x. For pif_show_2byte, 
pif_show_4byte, and pif_show_6byte there should be 2, 4, and 6 formatting 
codes, respectively. For pif_show_nbytes_hex, there should be a single %s 
formatting code, and n specifies the number of bytes to display, from 1 to 99. 
The PIF offset is updated. As a convenience, the byte, word, and long routines 
return the value displayed as the function result. 


void pif_show_ascii (len, prstr) /* Show ascii text 
int len; 7* Number of bytes to display 
char *prstr; 7* control string with embedded %s 


Create a new Detail line from ASCII text starting at the current offset. The 
caller provides a sprintf control string whose embedded $s is replaced with the 
ASCII string copied from frame data using pif_get_ascii. The PIF offset is 
updated. 


void pif_show_ebcdic (len, prstr) /* show ebcdic text 
int len; /7* number of bytes to display 
char *prstr; 7* control string with embedded %s 


Create a new Detail line from EBCDIC text, starting at the current offset. The 
caller provides a sprintf control string whose embedded ¢%s is replaced with the 
EBCDIC string copied from frame data using pif_get_ebcdic. (If ASCII 
translation is forced by the menus, this calls pif_show_ascii instead.) The 
PIF offset is updated. 
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void pif_show_lstring (prstr) /7* show lstring 
char *prstr; /*control string with an embedded %s 


Create a new Detail line from an ASCII Istring, starting at the current offset. 
An “lstring” starts with a length byte followed by that number of characters. 
The caller provides a sprintf control string whose embedded $s is replaced 
with the string copied from frame data using pif_get_lstring. The PIF offset 
is updated. 


void pif_show_flag (prstr, mask) 7* show flag byte 
char *prstr; /* title string: " = $d" is automatically added 
char mask; /* mask value indicating which bits to display 


This routine displays the value of a byte with bit flags and sets up the correct 
information for subsequent calls to show_flagbit. The PIF offset is 
incremented by 1. 


boolean pif_show_flagbit (bit, truestr, falsestr) 7* show flag bits 
char bit; /* Bit mask for 1 or more bits 

char truestr[]; 7* string to show if any masked bits are on 
char falsestr[]; 7* string to show if all bits are off 


This writes an 8-character field in the form "....1... <string>", indented as 
appropriate for the previous pif_show flag call. If the falsestr is NULLP, 
the truestr is used for both cases. Return TRUE if any of the specified bits 
were on. 


boolean pif_show_flagmask (mask, value, prstr) /* conditional show flags 
char maskbits; 7* Only check these bits 

char value; 7/* Check for this value 

char *prstr; 7* Write this string if matched 


Write a Detail line for a bit field only if the masked bits are a specified value. 
The line is written in the same format as for pif_show_flagbit. Return TRUE 
if the flag bits were the specified value and the line was written. 


void pif_show_date (prstr) /* show Unix-style date */ 
void pif_show_date_hl (prstr) 7* show Unix-style date */ 
char *prstr; 7* control string with embedded %s */ 


Create a new Detail line from the text given in prstr, with the %s replaced 
with a readable date and time such as "13-May-86 11:47:13." The date and 
time are taken from a 4-byte integer at the current PIF offset representing the 
number of seconds since 1/1/70 at midnight. The integer should be stored with 
the most significant byte first for pif_show_date_hl and with the least 
significant byte first for pif_show_date. The PIF offset is incremented by 4. 


void pif_show_space () 7* Gisplay a blank line 


Write a blank line to the Detail window. 
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void pif_header (len, prstr) /* Write a header line */ 

int len; 7* Length of area to highlight */ 

char *prstr; /* Header string */ 
Output a header line to the Detail window in the standard "----- header_text 


waee- " format, followed by a blank line. Highlight data starting at the current 
offset for the length specified. This routine does not update the PIF offset. 
This routine saves the header string in the global called called header_msg so 
other routines can use it. 


void pif_trailer () /7* write a trailer line */ 


Output a trailer line to the Detail window which reports on how much of the 
frame data was used by the interpreter, based on the final position of the 
PIF_offset. This routine uses the header string saved by pif_header. 


void pif_autoscroll () /7* set autoscroll position */ 


Make the next header line written to the Detail window with pif_header() be 
the one which is scrolled to the top when Summary highlighting is done. This is 
necessary only if the next header line is not the first for this registered PI. 


char *pif_line (len) 7* get detail line pointer */ 
int len; /7* Number of bytes to highlight and advance */ 


Return a pointer to a Detail line area. The caller also passes a length which 
causes the specified number of bytes (at the current PIF offset) to be 
highlighted in the hex window. The buffer pointer is advanced by the number 
of bytes specified. Beware of the side effects if you use this as the first 
argument to sprintf(); no other arguments should depend on the buffer 
pointer because compilers differ in the order of argument evaluation! 


void pif_set (address) /* set the PIF offset */ 
char *address; 


Set the PIF offset to the distance from the start of the frame data (dlc_header) 
to the specified address. This is a macro defined in pi.h. 


void pif_skip (delta) /* move the PIF offset */ 
int delta; 


Add the signed delta to the current PIF offset. This is a macro defined in pi-.h. 
char *pif_get_addr () 7* return frame data address x7 


Return the address of the data item at the current PIF offset. This is a macro 
defined in pi.h. 
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pi.h 
pifswitch.h 
network.h 
pifdecl.h 
initpi.c 
intnetbo.c 
intsmbo.c 
smb.h 
sample.c 
ENSNIFFC.LIB 
ENSNIFFP.LIB 
BUILD.BAT 
INSTALLM.BAT 


SAMPLE. ENC 


The programming environment for compiling and linking new 
Protocol Interpreters is that of Microsoft C Version 4.0. No other 
C compilers are supported. 


The hard disk’s subdirectory \ENSNIFF\NEWPI contains the files 
used to compile and link a new version of the Sniffer with modified 
or new Protocol Interpreters. Note that the compiler itself is not 
supplied; you must install it and the linker on the disk, using the 
installm batch file, which prompts you to supply the disks from 
Microsoft. This need be done only once. 


Files in the \newpi subdirectory are: 


Standard PI symbols 

Flags for PI choices 

Flags for the network type 
Function type declarations 
Protocol registration code 
NETBIOS stub code 

SMB stub code 

SMB structure declaration 
Source of the sample PI 
Library of Sniffer core modules 
Library of Sniffer PI modules 
Batch file to build the Sniffer 
Batch file to install Microsoft C on the hard disk. 
Frame data for the sample PI 
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The batch file build.bat can be used to compile and link a Protocol 
Interpreter that you write from scratch or a modified version of 
one of the “stub” interpreters for NETBIOS or SMB: 


This batch file ("build.bat") builds a new version of the Sniffer 
with user-written Protocol Interpreters. 


Supply the name of the new Protocol Interpreter source module as the 
argument to the batch file, as in "build myprot" or "build sample". 
If you are extending one of the stub interpreters for NETBIOS or 
SMB, then you would say "build intnetbo" or "build intsmbo". 

If you are compiling more than one, you should modify this batch 
file appropriately, or perhaps use the Microsoft MAKE facility. 


We assume that Microsoft Version 4.0 compiler and tools 
are located in the path \tools\mc and that the 

Microsoft C libraries are in \tools\mc\lib. 

(Note: If you get a linker error about /SE being invalid, 
you are using the wrong version of the linker!) 


path c:\;cs:\tools;c:\tools\mc;c:\dos; 


msc %1 /AL /Oat /J; 
if errorlevel 1 goto :end 


msc initpi /AL /Oat /J; 
if errorlevel 1 goto :end 


link initpi+%1,ensniff,ensniff,ensniffp+tensniffc+\tools\mce\lib\ 


/SE:500 /STACK:10000; 


if errorlevel 1 goto :end 


ensniff 


send 


In summary, the steps to take in writing a Protocol Interpreter 
are: 


e When writing a new PI (or when you which to register your 
extensions to an existing PI), modify initpi.c. 


® Write your C module, or modify the supplied stub routine. 


e Run the build batch file. 





Appendix C: Extending Protocol Interpreters 173 


Ethernet Version 





An Example Suppose that you want to write a new protocol interpreter for the 
“sample” protocol which has simple fixed-format data, like this: 


{1 byte] Device number 

{1 byte] Command type 

[2 bytes) Number of segments 

(20 bytes] Name of owner (asciiz) 


Suppose further that. this protocol data is sent using 802.3 LLC 
and DSAP hex 44. Using the existing interpreter registrations as 
an example, the following lines would be added at the appropriate 
places in initpi.c to register the new demultiplexed interpreter: 


/* In the declaration section... */ 
struct pi_data *pi_data_sample; 7* ptr to our PI data */ 
int interp_sample (void *, int); 7/* our PI function */ 
int simple_sap = 0x44; /* Gefine our SAP */ 
7* In the body of the initpi() function... */ 


pi_data_sample = 
register_pi ("Sample SAP", PITYPE_SAP, 1, &sample_sap, interp_sample, "SAMPLE: "); 


(Note that this code exists in initpi.c and can be actuated by 
changing the line #define SAMPLE 0 to #define SAMPLE 1.) 
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In a new module, you would then write your Protocol Interpreter 
with a structure something like this: 


/* Protocol Interpreter for the Sample Protocol */ 


#include "pi.h" 


extern struct pi_data *pi_data_sample; 7* our PI data */ 
extern char *dlc_header; /* start of the frame */ 
struct sample_header { 7/* the format of our header */ 


char device; 
char command; 


int nsegments; 
char owner [20]; 
} 
int interp_sample (header, length) /7* our interpreter */ 
struct sample_header *header; /7* pointer to our protocol header */ 
int length; 7* length of the data R/, 
if (pi_data_sample->do_sum) { /7* summary line wanted */ 
sprintf ( 
get_sum_line (pi_data_sample), /* get line buffer */ 


"SMP Device = %d, Cmd = %02X", 
header->device, header ->command) ; 


} 7* end of summary line */ 

if (pi_data_sample->do_int) { /7* Getail lines wanted */ 
sprintf ( 

get_int_line (pi_data_sample, 7* get a line buffer */ 

(char *)&header->device - dlc_header, /7* highlight offset af 

2) 7* highlight length */ 


, 
“Device = %d, command type = %02xX", 
header->device, header->command) ; 


sprintf ( 
get_int_line (pi_data_sample, 7* get line buffer */ 
(char *)&header->nsegments - dlc_header, /* highlight offset */ 
2), 7* highlight length */ 


"Number of segments = %d", 
header ->nsegments) ; 


sprintf ( 
get_int_line (pi_data_sample, 7* get a line buffer */ 
(char *)header->owner - dlc_header, 7* highlight offset */ 
20), 7* highlight length */ 


"Owner = %20s", 
header - >owner); 


} /* end detail lines +*/ 
/7* If there were any embedded protocol after our header, 

we could call the interpreters here. */ 

return length; 7* Say that we used up all the data */ 


} 
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The generation of lines for the Detail windows can be simplified by 
using the PIF formatting routines. That section of code, including 
the generation of header and trailer lines, might look like this 


instead: 
if (pi_data_sample->do_int) { /7* Getail lines wanted */ 
7* Set.up PIF globals. */ 


pif_init(pi_data_sample, header, length); 


7* Output the header line and highlight the whole header. 
Note that pif_header() does not alter the PIF offset. */ 


pif_header (sizeof (struct sample_header), 
"Sample Protocol Data Area"); 


/* Display the fields; each routine advances the buffer pointer 
past the data item just displayed. */ 


pif_show_byte ("Device number = %d"); 
pif_show_byte ("Command type = %02X"); 
pif_show_word ("Number of segments = %d"); 


pif_show_ascii (20, 


"Owner = %s"); 


7* Write out "End of..." message and check for excess/missing data. */ 


pif_trailer (); 
} 


7/* end of detail lines */ 


You would then build and test the new Sniffer with the command 
build sample. 


Programming and e 
Debugging Hints 


The LARGE memory model is used throughout the Sniffer and 
must be used by your Protocol Interpreters. This means 
that pointers are 4 bytes and integers are 2 bytes, so that 
the symbol nuLuP, not 0, should always be used to represent 
a null pointer. 


Extreme care should be taken in writing protocol 
interpreters, especially in the manipulation of pointers used 
as targets. There is no hardware memory protection, and 
with 4-byte pointers, there is no segment addressability 
limitation; every byte in the machine is vulnerable from a 
wayward pointer. Be particularly careful that incorrect or 
even totally random protocol data will not cause your 
interpreter to overflow strings, to access invalid memory 
areas, or to loop. 


The Microsoft Codeview debugger is unlikely to be a useful 
tool because of the size of the Sniffer executable module, but 
SYMDEB works just fine. 


Avoid the use of printf£() for debugging messages since the 
cursor is off the screen most of the time and the messages 
will not be seen. You can instead insert messages into the 
debugging window using the similarly-called debug_msq( ) 
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function; use Shift-F7 to pop up the debugging window. 
You can also insert debugging messages into the Detail 
window by using get_int_line(). If you must use 
printf(), specify DEBUG as a command line parameter when 
invoking the Sniffer and the cursor will be left somewhere 
on the screen, but the output will destroy the screen 
formatting. 


If you are decoding headers or data which are large, beware 
of interpreting invalid information beyond the end of the 
stored data. If the data were captured in “partial frame” 
mode, the data present may be less than the entire frame; 
the global bytes_not_stored indicates how much data is not 
present. 


Your Protocol Interpreter should not access data beyond the 
end of what has been stored for the frame. (Remember that 
some of the frame’s data may have been discarded if the 
partial-frame size was other than “whole frame” when the 
data was collected.) If you are using a PIF routine and it 
detects that it is about to access locations beyond the end of 
the frame data, it puts a frame too short message into the 
Detail window and it does not return to your Protocol 
Interpreter. 


Be careful not to store more than MAX_SUM_LINE characters 
in a Summary line buffer or more than MAX_INT_LINE 
characters in a Detail line buffer, regardless of what the 
frame data might be. 


Remember that the 80286 processor which is used in the 
Sniffer stores integers in low-high format. Depending on 
your protocol, you may have to reverse integers for printing 
or calculation. The PIF routines ending in _h1 are useful in 
that case. 


The Microsoft Version 4.0 compiler supports argument type 
checking using ANSI standard function prototyping. The 
#include files provided with the Sniffer have declarations 
for all the documented functions, and you are encouraged to 
add declarations of your new functions. 


The /g flag has been used to compile al] modules which 
makes the default for character variables unsigned. 


As discussed in the Microsoft C User’s Guide, the 
config.sys file in the root directory of the hard disk must 
specify at least FILES=15. If not, misleading errors like 
“cannot find xxx-h” will result. 
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° If you are using the PIF routines, it is necessary to use 
pif_save() and pif_restore() only if you are calling 
embedded protocol interpreters and you wish to generate 
more Detail window lines from the current interpreter after 
the embedded interpreter has returned. 
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Appendix D. A Brief Summary 
of the Ethernet Network Architecture 


Physical 
Interconnection and 
Speed 


Ethernet is a type of Local Area Network (“LAN”) suitable for 
high speed interconnection of computers and computer-controlled 
devices over moderate distances. The architecture of Ethernet is 
defined de facto by implementations from many manufacturers, 
and dejure as ANSI/IEEE standard 802.3, ISO/DIS standard 
8802/3, and FIPS standard 107. 


There are several variations permitted by the standards and other 
variations that are not official but are nonetheless popular, so to 
say that a network is “an Ethernet” means only that it is one of 
several closely-related but not necessarily compatible LANs. Even 
use of the word “Ethernet” itself may be confusing, since it is 
sometimes reserved to refer to the earlier “DIX” 
(DEC/Intel/Xerox) network, leaving “802.2 networks” to be used 
for the others. 


This appendix is a highly condensed summary of some features of 
Ethernet networks and their variations that are related to the use 
and understanding of the Sniffer" Network Protocol Analyzer. 


Stations connected to an Ethernet network are all connected to the 
same wire, so that every station hears what any station 
transmits. The delay between transmission and reception depends 
only on the propagation delays through the wires and attaching 
devices. In this way Ethernet differs fundamentally from 
networks like the IEEE 802.5 Token-Ring, where stations are 
wired in a logical ring so that each station only hears what its 
upstream neighbor transmits. 


The most common Ethernet transmission speed is 10 Megabits per 
second, or 1,250,000 bytes per second, sent in baseband (non- 
modulated, non-RF) form. The ANSIJ/IEEE documents refer to 
this as the “10BASE5” standard, which name encodes 10 Mb/s, 
Baseband, and 500 meters per segment. Another common standard 
is “1BASE5” over twisted-pair cable, which is based on AT&T’s 1 
Megabit per second StarLAN. Because of the access control 
mechanism described below, the effective network throughput is 
significantly less than the transmission speed. The “Ethernet 
Sniffer” supports LOBASE5 networks and some variants of it; 
there is a separate “StarLAN Sniffer” for LBASES5 networks. 
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Thick Ethernet 


Thin Ethernet 
(“Cheapernet’”’) 


There are two common schemes for the wiring of stations into an 
Ethernet. The original “thick Ethernet” scheme uses a backbone 
of yellow semi-rigid 0.4 diameter coaxial cable segments for up to 
100 stations per segment. Each segment is a maximum of 500 
meters long, and segments may be connected with repeaters 
subject to the restrictions that there are no more than 2 repeaters 
in the path between any two stations. Thus the maximum total 
cable length between two stations is 1500 meters but is often less 
than that in practice because of the way the cable is routed. The 
cable impedance is 50 ohms, and segments must be terminated on 
each end with a 50-ohm terminator attached with an N-series 
coaxial connector. The shield conductor must be grounded to an 
earth reference at only one point and fully insulated everywhere, 
including at connectors and terminators, to prevent shock hazards. 


A station is connected to a thick Ethernet cable by means of a 
transceiver,, which is a signal converter that must be attached 
directly to the cable. (Transceivers are called MAUs — Media 
Access Units — by the IEEE Standards documents.) Many 
transceivers clamp on to the cable and use a “vampire” tap to 
make contact with the outer shield and inner conductor without 
requiring that the cable be cut. The spacing between transceivers 
must be a multiple of 2.5 meters; the yellow cable has black 
marks to indicate possible transceiver attachment points. 


A single station is connected to its transceiver with a more flexible 
4-pair “drop cable” whose maximum length is 50 meters. In 
addition to carrying network data, the drop cable also supplies 
power for the transceiver electronics from the equipment being 
attached to the network. Both ends of the drop cable use DB-15 
connectors: a male connector with locking posts for the equipment 
end, and a female connector with a slide latch for the transceiver 
end. Note that the slide latch is often too big for the back panel of 
personal computers so at least two variations of this attachment 
scheme are in common use. 


To reduce the per-station cost of the transceiver and to circumvent 
the limit of 100 stations per segment, multiport transceivers are 
also available. These typically allow four or eight drop cables to 
be connected to a single box, which in turn is connected to a 
standard transceiver clamped to the coaxial cable segment. 


Another approach to reducing the cost of an Ethernet installation 
is “Cheapernet” or “Thin Ethernet.” It dispenses with the semi- 
rigid coaxial cable and separate transceivers. Instead, it uses 
flexible RG-58/U coax, and transceiver circuitry built into each 
attaching computer. For this wiring scheme, the overall topology 
is still a linear segment, but now the segment passes by the back 
of each computer. Attachment is made by splicing BNC 
connectors into the cable and inserting a “T” connector. The 
segments are still terminated with 50-ohm terminators at each 
end. The maximum length of a segment is usually 150 meters, 
although some vendors support larger distances. 
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Cheapernet transceivers are generally part of the network 
adapter circuitry and the exposed connector is thus a female BNC. 
A hybrid approach is also possible, since there are “Thin Ethernet 
Transceivers” available that attach with a standard drop cable to 
an attaching computer but have a female BNC instead of a 
vampire tap for connecting to the network. There are also “thin to 
thick” adapters that allow segments to be built out of both kinds of 
cable. Finally, some devices —like the Sniffer— provide both a 
BNC connector (for thin Ethernet) and a DB-15 connector (for a 
thin- or thick-Ethernet transceiver); on the Sniffer’s adapter, the 
position of a jumper determines which connector is active. 


Ethernet variations proliferate both with and without benefit of 
official standardization. Most share at least a philosophical 
tradition with the Ethernets discussed above, but are often 
incompatible in the sense that equipment designed for one species 
cannot be ‘connected with equipment designed for another. 
Prominent in this menagerie are: 


@ Broadband Ethernets, some of which run at 5 Mb/s so as 
to fit within a single television channel assignment. 


@ Twisted-pair Ethernets, designed for cabling often of the 
kind AT&T has designated PDS (“Premises Distribution 
System”); some proponents even allege reliable operation at 
10 Mb/s. 


e Star-wired Ethernets, with centralized collision detection 
rather than a common bus system. 


e Fiber-optic Ethernets, most of which use two cables per 
station and a centralized optical coupler to rebroadcast the 
transmitted signal to all receivers. 


All the Ethernet variants that a have rightful claim to the name 
use an algorithm to control transmission called “Carrier Sense 
Multiple Access with Collision Detection,” abbreviated as 
CSMA/CD. Before transmitting, a station waits until it sees no 
other station transmitting; it is thus deferring until it senses no 
“carrier” from another station. It then begins sending its 
message. Since there is the possibility that another station 
decides to transmit at roughly the same time, the sending station 
monitors the network to see that its own message appears on the 
network ungarbled. If it detects a collision with another message, 
it intentionally sends a few additional bytes (a process called 
“jamming”) to ensure propagation of the collision throughout the 
system to all other transmitting stations. The station then 
remains silent for a random amount of time (controlled by a 
“backoff algorithm”) before attempting to transmit again. 


Collisions may be seen by receiving stations as badly-formatted 
frame fragments called “runts” which are typically shorter than 
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the minimum frame size and have incorrect check words; they 
may also have an incorrect starting sequence and not be seen as 
the start of a frame at all. Note that since the propagation time 
through the network is typically much longer than the 
transmission time for a bit, different receivers will see different 
effects depending on their position relative to the various 
transmitters. 


In addition to deferring to active traffic, no station will begin a 
transmission until at least 9.6 microseconds after the end of a 
transmission. This enforced interframe spacing allows time for 
receivers to recover from one frame and prepare to receive the 
next. 


Besides moving serial data to and from the attached device and 
the network, the transceiver has several other functions: 


e Collision detection: The fourth wire pair in the drop cable 
transmits the “collision detect” signal (called “signal quality 
error” or SQE in IEEE documents) from the transceiver to 
the device. In addition to its use to control transmission, 
this signal can also be used to detect some network and 
transceiver failures. 


2 Jabber detection: The transceiver is required to disable 
transmission if the device transmits for longer than the 
longest possible frame. This prevents some kinds of device 
failures from halting network activity, but is not foolproof. 


All data in a frame is transmitted as a sequence of 8-bit bytes, 
each sent Manchester phase-encoded, starting with the least- 
significant bit. The format of each frame is as follows: 


First ————_________» Transmission order ————_—________—_——_> Last 


Preamble 
8 bytes 


11 

Destinat’n Source Data FCS 

6 bytes 6 bytes 48..1502 bytes 4 bytes 
A 


|«——_——__ Recorded by the Sniffer ——____» 


The preamble is a fixed data pattern used for receiver synchro- 
nization and recognition of the start of a frame. The destination 
and source addresses are each 6 bytes. Various kinds of broadcast 
addresses are indicated if the first transmitted bit (the low-order 
bit of the first byte) of the destination address is a one. Note that 
the IEEE 802.3 standard also permits 2-byte source and 
destination addresses, but their use is rare and inconsistent with 
10BASE5. 


The data field must be a minimum of 48 bytes so that the frame is 
at least 64 bytes; this is necessary so that the duration of a 
frame is longer than the 45 microsecond worst-case round trip 
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delay through the network. If this were not true then collisions 
might not be detected. The IEEE 802.3 standard permits other 
limits on the frame size for non-LOUBASE5 networks only. 


Following the data is a 4-byte Frame Check Sequence which 
checks the validity of the source, destination, and data fields. The 
Sniffer does not record the FCS but will optionally collect and 
identify frames whose FCS is incorrect. 


To specify how the initial bytes of the data field are to be 
interpreted, there are two conventions in general use. The original 
format as defined by Xerox, now often called the “Ethernet” 
format (in contradistinction to the IEEE 802.3 format), contains 
no length field and begins with a 2-byte “Ethertype” field which 
indicates the major protocol type. For example, the IP protocol of 
TCP/IP is assigned the Ethertype hex 0800. 


rotocol 


/ 
Ethertype P data 
2 bytes 46..1500 bytes 
71 


The assignment of Ethertypes to protocols was originally done by 
Xerox and has now been taken over by US Defense Communi- 
cations Agency. 


The second convention for interpretation of the data field is that 
supported by the IEEE/ANSI/ISO standards organizations for 
802.3 networks, and begins with a 2-byte length (most significant 
byte first), followed by a Logical Link Control header which 
conforms to the IEEE 802.2 standard: 


11 
Length DSAP SSAP Control Protocol data 
2 bytes 1 byte 1 byte 1..2 bytes 42..1497 bytes 
1 


|«——_—__— 802.2 LLC ——_____ > | 


LLC Frames 


Note that although both data formats can and do appear on the 
same network, there is in theory no foolproof way to distinguish 
between the two by looking at the frame. In practice, though, it 
turns out that almost all assigned Ethertypes are numerically 
larger than the maximum frame length of 1500. Thus if the first 
two bytes of frame data are larger than 1500 it is probably an 
Ethernet/Ethertype frame. (The only common exception is the 
PUP Ethertype, hex 0200.) 


The Sniffer can decode frames in either format, and can make the 
format decision automatically or be instructed by the operator. 


A frame that conforms to the 802.2 standard is a Logical Link 
Control frame. LLC is a protocol that provides reliable connection- 
oriented or connectionless virtual circuits between processes. 


LLC frames are controlled with a 3 or 4 byte header, the first two 
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bytes of which are the Destination and Source Service Access 
Points (SAPs). The SAP numbers are preassigned codes that 
indicate which sub-protocol the rest of the frame belongs to. For 
example, the NETBIOS protocol has been allocated a single SAP 
(hex FO), and SNA has been allocated four SAPs (hex 04, 05, 08, 
and 0c). The Source and Destination SAPS (SSAP, DSAP) are 
almost always the same except in frames that are establishing an 
initial SNA connection. 


There are three LLC frame types: 


© I frames contain arbitrary sequenced data interpreted by 
the protocol that the SAPs designate. The LLC header 
contains a send sequence number N(S) for this frame and a 
receive sequence number N(R) of the next frame expected 
from the other station. 


® Supervisory frames do not contain or consume an N(S) 
number, but do contain N(R). In addition they can contain 
the following indications as either a command or a response: 


RR Receive Ready; transmission can proceed. 
RNR Receive Not Ready; transmission is blocked. 
REJ Reject; retransmission starting with N(R) is 
requested. 
e Unnumbered format frames contain neither N(S) nor 


N(R), but may contain control information or data. There 
are the following types: 


SABME = Set. Asynchronous Balanced Mode Extended; 
establish a virtual connection, also called a link. 


DISC Disconnect; terminate a virtual connection. 

DM Disconnected mode; the connection is broken. 

UA Unnumbered acknowledgement; for SABME and 
DISC response. 

FRMR Frame reject; the format of a received frame 
was bad. 

XID Exchange identification; for negotiation of LLC 
services. 

TEST Test probe; should be echoed by the receiving 
station. 

UI Unnumbered information; used by the SAP 


protoco! for any purpose. 
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The only LLC frames that are allowed to contain data after the 
LLC header are I, UI, TEST, XID, and FRMR types. 


Note that the minimal use of LLC is to make every frame a UI 
type, in which case the data part of every frame begins with five 
bytes: the two-byte length field, the two SAP bytes and a UI (hex 
03) control byte. This technique is typically used to implement 
various higher level protocols that do connection control and 
sequencing themselves and therefore do not need the services of 
the standard LLC, but where compatibility with LLC formats is 
important. 


The 6-byte node addresses are divided into a initial 3-byte code 
representing the manufacturer of the equipment, and a unique 3- 
byte serial or sequence number assigned to that piece of 
equipment. The responsibility to assign manufacturer codes was 
initially takén by Xerox but has now been assumed by the IEEE. 


It is the intention of the JEEE that the same code be used for all 
networks supported by a manufacturer, including 
Ethernet/StarLAN (802.3) and Token-Ring (802.5). However, the 
fact that Ethernet/StarLAN bytes are transmitted with the least- 
significant bit first and Token-Ring bytes are transmitted with the 
most-significant bit first has led to considerable confusion in the 
way that assigned addresses are used. 


The IEEE’s clearly stated position is that the assigned code 
specifies how the address should appear on the network cable; the 
result being that a network address stored in a computer’s 
memory will be different depending on what the originating 
network was. Since network addresses appear at various places 
within the protocol levels of a frame, and since a frame may have 
been forwarded by various network types, this imposes a difficult 
burden on network software. In fact, observation of network 
software and hardware from a variety of vendors shows that most 
have chosen to use the same address as it appears in memory on 
both networks, thus using a code on one or the other network that, 
according to the IEEE interpretation, is not assigned to them. 
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Appendix E. Glossary of Acronyms and 
Specialized Terms 


AC 


ACTPU 


APPC 


ARCNET 


ARP 


ASCII 


Baseband 


BIND 


BIS 


BOOTP 


Broadband 


Broadcast 


BNC 


CGA 


Access control; a DLC byte on IEEE 802.5 Token-Ring networks 
that contains the token indicator and frame priority information. 


Activate Physical Unit; an SNA message sent to start a session. 


Advanced Program-to-Program Communications; a communica- 
tions system used to communicate between transaction programs 
on IBM computers; APPC uses the LU 6.2 subset of SNA. 


A baseband token-passing network designed by the Datapoint 
Corporation which communicates among up to 255 stations at 2.5 
Mb/s. 


Address Resolution Protocol; a protocol within TCP/IP for finding a 
node’s DLC addresses from its IP address. 


American Standard Code for Information Interchange; a mapping 
between numeric codes and graphical characters used almost 
universally for all personal computer and non-IBM mainframe 
applications. 


A modulation technique that sends data bits without using a much 
higher carrier frequency. The entire bandwidth of the 
transmission medium is used by one signal. 


An SNA message sent to activate a session between LUs. 


Bracket Initiation Stopped; an SNA message sent to indicate that 
the sending station will not attempt to initiate any more brackets. 


Boot Protocol; a protocol within TCP/IP that is used for 
downloading initial programs into networked stations. 


A modulation technique that sends data bits encoded within a 
much higher radio-frequency signal. The transmission medium 
may be shared with other simultaneous signals since each only 
uses part of the available bandwidth. 


(1) A message directed to all stations on a network or collection of 
networks. (2) A destination address which designates all stations. 


A standardized coaxial cable connector; used for Thin Ethernet 
(“Cheapernet”) cables and ARCNET networks. 


Color Graphics Adapter; the interface between a personal com- 
puter and a medium-resolution color monitor. 
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CRC 


CSMA/CD 


CTERM 


DAP 


DB-9 


DB-15 


DB-25 


DFC 


DISC 


DLC 


DLL 


DM 


DNS 


DOS 


DRP 


DSAP 


Cyclic Redundancy Check; a check-word, typically four bytes at 
the end of a frame, used to detect errors in the data portion of the 
frame. 


Carrier Sense Multiple Access with Collision Detection; the 
algorithm used by IEEE 802.3 and Ethernet networks to control 
transmission. 


Command Terminal; a _ protocol within DECNET for 
communicating with generic intelligent terminals, i.e., a virtual 
terminal protocol. 


Data Access Protocol; the DECnet protocol which provides remote 
file access. 


A 9-pin standardized connector used in personal computers for the 
Token-Ring network connection, serial I/O port, and RGBI output. 


A 15-pin standardized connector used to connect to the drop cable 
of an IEEE 802.3 or Ethernet transceiver. 


A 25-pin standardized connector used in personal computers for 
printer parallel output ports. 


Data Flow Control; an SNA subprocess for reliable message 
transfer. 


Disconnect; an LLC non-data frame indicating that the connection 
established by an earlier SABME is to be broken. 


Data Link Control; the lowest protocol level within the transmitted 
network frame; fields typically include the Destination address, 
and Source address, and perhaps other control information. 


Downline load; a protocol within the Datapoint RMS family used 
for downloading initial programs into networked stations. 


Disconnected mode; an LLC message acknowledging that a 
previously established connection has been broken. 


Domain Name Service; a protocol within TCP/IP for finding out 
information about resources using a database distributed among 
different name servers. 


Disk Operating System; the most common operating system for 
IBM-compatible personal computers. 


DECnet Routing Protocol; the lowest-level DECnet protocol which 
is concerning with moving packets from endnodes through routers 
to other endnodes. 


Destination Source Access Point; the LLC SAP for the protocol ex- 
pected to be used by the destination station in decoding the frame 
data. 
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EBCDIC 


EGP 


Ethernet 


Ethertype 


FC 


FCS 


FID 


FMD 


FMH 


Found 


Frame 


FRMR 


FS 


FS CMD 
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Extended Binary-Coded-Decimal Interchange Code; a mapping 
between numeric codes and graphical characters used for IBM 
mainframe computers and communications protocols defined by 
IBM. 


Exterior gateway protocol; a protocol within TCP/IP used to 
exchange routing information among gateways belonging to the 
same or different systems. A generalization of GGP. 


A CSMA/CD network standard originally developed by Xerox; 
similar to (and often used interchangeably with) the IEEE 802.3 
standard. 


A 2-byte protocol-type code in Ethernet frames used by several 
manufacturers but independent of the IEEE 802.3 standard. 


Frame control; on a Token-Ring network, the DLC byte that 
contains the frame’s type. 


Frame check sequence; a redundant check field used to increase 
the probability of error-free transmission on the network. 


Format Identification; a field in the SNA Transmission header in- 
dicating the type of nodes participating in the conversation. LU 
6.2 nodes are type 2. 


Function Management Data; a class of data embedded at the start 
of SNA RUs. 


Function Management Header; the header part of SNA FMD con- 
taining addressing and transmission control information. 


Foundation Services; a protocol within DECNET used for primitive 
terminal-handling services. 


The multi-byte unit of data transmitted at one time by a station 
on the network; synonymous with Packet. 


Frame Reject; an LLC command or response indicating that a 
previous frame had a bad format and is being rejected. The REJ 
frame contains five bytes of data explaining why and how the 
previous frame was bad. 


Frame status; a byte appended to a Token-Ring network frame 
following the CRC. It contains the Address Recognized and Frame 
Copied bits. 


Fileserver commands; a protocol used by Nestar to issue 
commands from client stations to servers. 


File Transfer Protocol; a protocol within TCP/IP for reliable file 
transfer. 
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Functional address 


GGP 


Hub 


ICMP 


IEEE 


IOB 


IONET 


IP 


ISO 


LLC 


LOOP 


LSA 


LUSTAT 


A limited broadcast destination address for IEEE 802.5 Token- 
Ring networks. Individual bits in the address specify attributes 
which station eligible to receive the frame should have. Similar to 
“multicast address.” 


Gateway-to-gateway protocol; a protocol within TCP/IP used to 
exchange routing information among IP gateways. See also EGP. 


A concentrator and repeater for the StarLAN or the ARCNET 
network. For StarLAN, it is more properly known as a Network 
Hub Unit or as a Network Extension Unit. 


Information; an LLC frame type used to send sequenced data 
which must be acknowledged. 


Internet Control Message Protocol; a protocol within TCP/IP used 
principally to report errors in datagram transmission. 


Institute of Electrical and Electronics Engineers, Inc. Standards 
documents are available from them at 345 East 47th Street, New 
York, NY 10017. 


Input/Output block protocol; used by Nestar to make virtual disk 
requests from client station to servers. 


Input/Output Network; a device message protocol used by 
Datapoint. 


Internet Protocol; the lowest-level protocol under TCP/IP, which is 
responsible for end-to-end forwarding and long packet 
fragmentation control. 


International Organization for Standardization; (1) a consortium 
which is establishing a suite of networking protocols and (2) the 
protocols standardized by that group. 


Local Area Network; the hardware and software used to connect 
computers together in a limited geographical area. 


Local Area Transport; the DECNet protocol which handles 
multiplexed terminal (keyboard and screen) traffic to and from 
timesharing hosts. 


Logical Link Control; a protocol which provides connection control 
and multiplexing to subsequent embedded protocols; standardized 
as IEEE 802.2 and 1SO/DIS 8802/2. 


Loopback protocol; a protocol under Ethernet for sending diag- 
nostic probe messages. 


Lost Subarea; an SNA error condition. 


Logical Unit Status; an SNA message used to send status infor- 
mation. 
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LU 6.2 


MAP 


MAU 


MAC 


MOUNT 


MOP 


Multicast 


NC 


ND 


NETBIOS 


NetWare 


NEU 


NFS 


NHU 


NICE 


N(R) 


Ethernet Version 


Logical Unit 6.2; a subset of the SNA protocols used for peer-to- 
peer communications between computers. 


Manufacturing Automation Protocol; an emerging multi-layer net- 
working protocol developed primarily by General Motors for manu- 
facturing control applications. 


Multiple Access Unit, Media Access Unit; the wiring concentrator 
or transceiver used for attaching stations connected to the 
network. 


Media Access Control; the protocol level which describes network 
management frames sent on the 802.5 Token Ring. Most MAC 
frames are handled transparently by the network adapter. 


A protocol developed by Sun Microsystems for handling request 
access checking and user validation. It is used in conjunction with 
NFS. 


Maintenance Operations Protocol; a protocol under DECnet for 
remote testing and problem diagnosis. 


(1) A message directed to a subset of the stations on a network or 
collection of networks. (2) A destination address which designates 
such a subset. 


Network Control; an SNA subprocess. 


Network Disk; a protocol within the SUN NFS family used to 
access virtual disks locately remotely across the network. 


Network Basic I/O System; (1) A protocol implemented by the PC 
LAN Program to support symbolically named stations and 
arbitrary data. (2) The programming interface used to send and 
receive NETBIOS messages. 


The networking system designed by Novell Inc.; the protocols used 
therein. 


Network Extension Unit; a concentrator and repeater for 
StarLAN networks. 


Network File System; a protocol developed by SUN Microsystems 
for requests and responses to a networked file server. 


Network Hub Unit; a concentrator and repeater for StarLAN 
networks. 


Network Information and Control Exchange; the DECnet protocol 
for network management. 


Receive sequence number; an LLC field for I frames which indi- 


cates the sequence number of the next frame expected; all frames 
before N(R) are thus implicitly acknowledged. 
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N(S) 


NSP 


OpenNET 


Packet 


PCF 


PC*l 


PDU 


PEP 


PI 


PMAP 


PUP 


RARP 


REJ 


REM 


RG-58 


RG-62 


RGBI 


Send sequence number; an LLC field for I frames which indicates 
the sequence number of the current frame within the connection. 


Network Services Protocol; the DECNet protocol that provides 
reliable message transmission over virtual circuits. 


A networking system from the Intel Corporation, using parts of 
the OSI standards and components of the Microsoft/IBM PC LAN 
program. 


The multi-byte unit of data transmitted at one time by a station 
on the network; synonymous with Frame. 


Physical Control Fields; the part of the Token-Ring DLC header 
that includes the AC and FC fields. 


Personal Computer Integration; Data General’s nomenclature for 
their networking system. Protocols used include the ISO IP and 
TP4 levels and the Microsoft(IBM PC LAN program SMB 
protocols. 


Protocol Data Unit; the data delivered as a single unit between 
peer processes on different computers. 


Packet Exchange Protocol; a protocol within the XNS family used 
to exchange datagrams. 


Protocol Interpreter; a program which knows the frame format 
and transaction rules of a communications protocol and can decode 
and display frame data. 


Port Mapper; a protocol developed by SUN Microsystems for 
mapping RPC program numbers to TCP/IP port numbers. 


PARC Universal Packet; a type of Ethernet packet developed at 
the Xerox Corporation’s Palo Alto Research Center. 


Reverse Address Resolution Protocol; a protocol within TCP/IP for 
finding a node’s IP address given its DLC address. 


Reject; an LLC frame type which requests retransmission of 
previously sent frames. 


Ring Error Monitor; a station on the 802.5 Token-Ring network 
that collects MAC-level error messages from the other stations. 


The designation for 50-ohm coaxial cables used by Cheapernet 
(thin Ethernet). 


The designation for 93-ohm coaxial cables used by ARCNET. 
Red-Green-Blue-Intensity; an interface used for attaching a color 


monitor to a personal computer; DB-9 connectors are typically 
used. 
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RH 


RI 


RIP 


RJ-45 


RMS 


RNR 


RPC 


RPL 


RPS 


RR 


RSTAT 


RU 


RUnix 


SABME 


SAP 
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Request/response header; an SNA control field prior to a Request 
Unit or Response unit. 


Routing Indicator; the first bit in the source address field of a 
Token-Ring frame, which if 1 says that the data field begins with 
Routing Information. 


Routing Information protocol; a protocol within the XNS family 
used to exchange routing information among gateways. 


The designation for the 8-wire modular connectors used for 
StarLAN networks. It is similar to, but wider than, the standard 
phone modular connectors. 


Resource Management System; a set of protocols used by 
Datapoint to communicate from client stations to servers. 


Receive Not Ready; an LLC command or response indicating that 
transmission is blocked. 


Remote Procedure Call; a protocol for activating functions on a 
remote station and retrieving the result. There are Xerox XNS 
and SUN Microsystems versions of RPC protocols, among others. 


Remote Program Load; a protocol used by IBM on the IEEE 802.5 
Token-ring network to download initial programs into networked 
stations. 


Ring Parameter Server; a station on the Token-Ring network 
which maintains MAC-level information about the LAN configu- 
ration such as ring numbers and physical location identifiers. 


Receive ready; an LLC non-data frame indicating readiness to re- 
ceive data from the other station. 


Remote status; a protocol with the SUN NFS family used to 
exchange statistics on network activity. 


Request Unit/Response unit; the part of an SNA frame after the 
RH which contains the details of a request or its response. 


Remote Unix; a protocol under TCP/IP for issuing remote requests 
over the network to a UNIX host. 


Set Asynchronous Balanced Mode Extended; an LLC non-data 
frame requesting the establishment of a connection over which 
numbered J frames may be sent. 


Service Access Point; a small number used by convention or 
established by a standards group, that defines the format of sub- 
sequent LLC data; a means of demultiplexing alternative protocols 
supported by LLC. 
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SBI 


SC 


SCP 


SDLC 


SIG 


SMB 


SMTP 


SNA 


SPP 


SQE 


SSAP 


SSCP 


StarLAN 


SUA 


TC 


Stop Bracket Initiation; an SNA message sent to request that the 
other station not initiate any more brackets. 


Session Control; an SNA _ subprocess for establishing and 
maintaining connections. 


Session Control Protocol; the DECnet protocol concerned with the 
establishment of virtual circuits over which NSP transfers data. 


Synchronous Data Link Control; an older serial communications 
protocol which was the model for LLC and with which it shares 
many features. 


Signal; a high-priority SNA message used to request permission to 
send. 


Server Message Block; a message type used by the IBM PC LAN 
Program to make requests from a user station to a server and 
receive replies. Many of the functions are similar to those made 
by an application program to DOS running on a single computer. 
Under the IBM PC LAN Program, SMBs are sent as data within 
NETBIOS frames. 


Simple Mail Transfer Protocol; a protocol within TCP/IP for 
reliable exchange of electronic mail messages. 


Systems Network Architecture; a complex set of protocols used by 
IBM for network communications, particularly with mainframe 
computers. 


Sequenced Packet Protocol; the subset of XNS which supports 
reliable connections using sequenced data. 


Signal Quality Error; the 802.3/Ethernet collision signal from the 
transceiver. 


Source Service Access Point; the LLC SAP for the protocol used 
by the originating station. 


System Services Control] Point; an SNA identification of communi- 
cations management functions. 


A network developed by AT&T—Bell Labs and based upon a 
derivative of the COMA/CD (Ethernet) network standard originally 
developed by Xerox; similar to (and often used interchangeably 
with) the IEEE 802.3 standard. 


Stored Upstream Address; the network address of a Token-ring 
station’s nearest upstream neighbor. Texas Instruments calls this 


the “UNA.” 


Transmission control; an SNA subprocess. 
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TCP/IP 


TCP 


TELNET 


TFTP 


TH 


Token 


Token-bus 


Token-ring 


TP4 


TRAILERS 


TS 


UA 


UDP 


UI 


UNA 


UNIX™™ 
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Transmission Control Protocol/Internet Protocol; a suite of 
networking protocols developed originally by the US Government 
for Arpanet and now used by several LAN manufacturers. (The 
individual TCP/IP protocols are separately listed in this Glossary.) 


Transmission Control Protocol; the protocol within TCP/IP which 
provides reliable end-to-end communication by using sequenced 
data sent under IP. 


A protocol within TCP/IP for transmitting character-oriented 
terminal (keyboard and screen) data. 


Trivial File Transfer Protocol; a protocol within TCP/IP used to 
exchange files between networked stations. 


Transmission header; the initial part of an SNA _ frame 
immediately following the LLC header. 


A small message used in some networks to represent the 
permission to transmit; it is passed from station to station in a 
predefined sequence. 


A type of LAN where all stations can hear what any station 
transmits and where permission to transmit is represented by a 
token sent from station to station. 


A type of LAN where stations are wired in a ring and each can 
directly hear transmissions only from its immediate neighbor. 
Permission to transmit is granted by a token that circulates 
around the ring. 


The designation for the variation of the ISO transport-level 
protocol which contains the most functionality. 


A variant form of TCP/IP frames where the descriptive protocols 
headers are relocated to follow the user data. 


Transmission services; an SNA subprocess. 


Unnumbered Acknowledgment; an LLC frame which 


acknowledges a previous SABME or DISC request. 


User Datagram Protocol; a protocol within TCP/IP for sending 
unsequenced data frames not otherwise interpreted by TCP/IP. 


Unnumbered Information; an LLC frame type used to send data 
without sequence numbers. 


Upstream Neighbor Address; the network address of a Token-Ring 
station’s nearest upstream neighbor. IBM calls this the “SUA.” 


A popular portable operating system written (and trademarked) 
by AT&T. 
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196 


VINES'™ 


XNS 


YP 


IBASE5 


LOBASES5 


38COM 3+ 


802.2 


802.3 


802.5 


The networking operating system developed by Banyan Systems 
Inc. and the protocols used therein. Notable components are 
StreetTalk and MatchMaker. 


Exchange Identification; an LLC unnumbered frame type used to 
negotiate what LLC services will be used during a connection. 


Xerox Network Systems; a family of protocols standardized by 
Xerox; in particular the Internet Transport Protocols. Documents 
are available from Xerox Document Systems Business Unit, 475 
Oakmead Parkway, Sunnyvale, CA 94086. 


Yellow Pages; a protocol developed by SUN Microsystems for 
implementing a distributed resource lookup database; similar in 
function to DNS. 


The implementation of IEEE 802.3 (StarLAN) standard using 1 
megabit per second transmission on a baseband medium whose 
maximum segment length is 500 meters. 


The implementation of the IEEE 802.3 (Ethernet) standard using 
10 megabit per second transmission on a baseband medium whose 
maximum segment length is 500 meters. 


A networking system from 3COM Corporation, which uses parts 
of the XNS and Microsoft/IBM PC LAN program protocols. 


The IEEE standards designation for the LLC Sublayer protocol 
which provides both datagram and_ *reliable connection 
transmission. 


The IEEE standards designation for the CSMA/CD network access 
method; similar to (and often used interchangeably with) Ethernet. 


The IEEE standards designation for the Token Ring network 
access method. 
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Appendix F. Sniffer Specifications 


Product Name: 
Model Number: 
Package: 
Weight: 


Power: 


Processor: 


Memory: 


Storage: 


Display: 


Keyboard: 


Network: 


Printer Port: 


Protocol Interpreters: 


Ethernet Network Portable Protocol Analyzer. 
PA-302. 

Portable instrument with extendable handle. 
Approximately 19 lbs. in use, 31 Ibs. as shipped. 


Built-in voltage selection switch for either 115 VAC or 230 VAC; 
11’ US line cord. 


Intel 80286-12 at 12 Mhz. 


640 KB of standard RAM and 384 KB of expanded/extended 
memory. 


One 720 KB 3.5" internal double-sided, double-density diskette 
drive; one 40 MB internal hard disk. 


10.25" internal gas plasma display panel; one DB-9 connector for 
external RGBI color monitor. 


Typewriter-style keyboard with function keys. 


One DB-15 connector (female) to accept the corresponding 
connector and cable linking the Sniffer to an Ethernet transceiver. 
Neither the transceiver nor its connecting cable are supplied as 
part of the Sniffer. However, the Sniffer includes a lockpost 
adapter plate to convert the lockpost clips found on the standard 
Ethernet DB-9 connector to the screw posts provided on the 
Sniffer’s DB-15 jack. 


One DB-25 connector for a parallel Centronics-compatible printer 
or for an external 5.25" diskette drive. 


One DB-9 connector for a serial printer or a modem. 

Includes DLC, LLC, LOOP, and SNAP as standard. The following 
interpreters may be ordered, and when ordered with the Sniffer, 
are supplied already installed. 


Novell NetWare. Includes XNS, Netware Core Protocol. 


XNS/MS-NET. Includes XNS (SPP, PEP, RIP), SMB (e.g., 
3COM 3+, U-B, etc.) 


TCP/IP. Includes ARP, TCP, IP, UDP, ICMP, SMTP, FTP, 
TELNET, NETBIOS. 


SUN. Includes SUN RPC, NFS, YP, MOUNT. Requires the 
TCP/IP Protocol Suite. 
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Software: 


Warranty: 


Copyright: 


ISO/MS-NET. Includes TP4/IP, SMB (e.g., OpenNET, PC*1). 


DECnet. Includes MOP, DRP, SCP, NSP, DAP, NICE, LAT, 
SMB. 


Others may have been added since publication of this Manual. 
Written in a combination of microcode, machine language, and C. 
Source code is not provided, but end-user extensions for 
proprietary protocols are supported. 


One year. 


Software, manuals, and screen formats (“look and feel”) are all 
copyright by Network General Corporation. 
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Appendix H. Troubleshooting Checklist 


Please fill in: 


Phone number, Network 
General’s Customer 
Service Department: 


Serial number 
of your Sniffer: 


Check First 


If there is nothing on the 
screen 


If the Sniffer program 
does not start 


If there is no output on the 
external color screen 


If the keyboard or display 
is too low for comfort 


When you suspect a problem with the Sniffer equipment or 
software, please look through this check list before contacting us. 
Many times we find that correcting a simple oversight can save 
you (and us) lots of time. 


1. Check the power cable and power source. 
2. Check the power switch (left side, back). 


3. Make sure the monitor screen intensity control under the 
floppy disk drive is turned up (clockwise). 


1. Make sure there is no diskette in the floppy drive when you 
start the Sniffer. (This may produce the message Non- 
system disk or disk error.) 


2. Doublecheck any modifications you might have made to the 
startup file autoexec.bat on the hard disk. 


1. Make sure you select External color monitor in the selection 
menu when you start the Sniffer. 


2. Check that the monitor is working and adjusted properly. 


1. Extend the flaps under the keyboard, and erect the bottom 
support under the display unit. 
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If you get the warning 
about “Not enough 
memory” or “This is 
running on a slow 
computer” 


If a full size capture buffer 
cannot be allocated 


If you cannot capture data 
from the network 


If you don’t see traffic that 
you expect 


If a pattern-match filter or 
trigger doesn’t seem to 
work 


If you get the message “No 
frames selected for 
display” 


You may want to remove any resident programs you have 
installed, such as ProKey or Sidekick. They take both 
memory space and time. 


Make sure you did not change the processing speed by using 
the CTRL-ALT-\ key combination. 


Don’t worry. You can still collect data even if the Sniffer 
doesn’t have room to allocate a full 256K buffer. The 
message explains how large a buffer has been allocated. 


Follow some of the steps mentioned in answer to the 
preceding problem to make more room for the Sniffer’s 
buffers. 


If you are unable to free sufficient space because you are 
keeping a large number of protocol interpreters active at the 
same time, you may wish to rebuild the Sniffer software so 
as to minimize the space consumed by Pls. Contact the 
technical department at Network General for advice on 
whether or how to do this. 


Check the connection from the DB-15 connector on the 
Sniffer’s Ethernet adapter to the Ethernet cable. 


Check the connection from the Ethernet cable to the 
transceiver. 


Check the transceiver, using the instructions provided by its 
manufacturer. ‘The transceiver may include a light 
indicating when it is receiving a signal (from the station to 
which it is connected, in this case the Sniffer). Try 
connecting a different station to the same transceiver or the 
Sniffer to a different transceiver. 


Make sure that the capture submenu says From 
<Ethernet>. 


Check the station, protocol, and pattern-match capture 
filters to see whether traffic is being discarded. If the 
“frames seen” count is larger than the “frames accepted” 


count, then frames are being discarded. 


Check the protocol and station-address filters; they may be 
causing the frames of interest to be discarded. 


Doublecheck the offset; detection of a pattern depends on 
telling the Sniffer both what to look for and where to look. 


Change the station address display filter, or 
Change the protocol display filter, or 


Change the pattern-match display filter. 
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If you don’t see frames 
that you expect 


Ifa “from” or “to” filter 
isn’t working 


If network utilization 
seems too low 


If you are not seeing 
symbolic station names 


If HELP information is 
not available 


If you aren’t getting any 
print output 


Ethernet Version 


Make sure that the display and capture filters are not 
mutually exclusive. 


Check the display filters. 


Check the capture filters, since they may have caused the 
frames to be discarded. 


Check the setting of the “reverse direction” option in the 
filter menu. 


Check the settings of other filters involved in capture or 
display; what you see displayed is what passes through all 
the filters. 


Check the display filters. Remember that only frames 
displayed are used in the network utilization calculation. 
Sometimes lower-level protocols which are not displayed 
carry much of the actual data. 


Do some reasonableness checks based on the frame sizes. 
The utilization might indeed be correct! 


Use the Manage Names menu item to examine and add to 
the names list. 


Remember to Save Names to make a permanent record of 
any changes. 


Make sure the file sraRTuP.END is in the default. directory or 
in the directory specified by the DOS environment string 
SET ENNAMES=xxx. 


Make sure the file ENSNIFF.HLP is in the default directory or 
in the directory specified by the DOS environment string SET 
ENHELP=xxx. 


Make sure the various help files are in a subdirectory called 
HELP within the same directory as ENSNIFF.HLP. 


Check the printer itself (power, switch settings, etc.). 


Check the cable to the printer. For serial printers make 
sure you are connecting to the Sniffer’s slot 1 male DB-9 
connector and not one of the female DB-9 connectors. 


For serial printers, make sure that the transmit and receive 
? 

pins are wired correctly. For some printers you may need a 

“null modem” cable. 


For serial printers, make sure that. you have issued the 


appropriate MODE command to set the baud rate, word size, 
parity, etc. 
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If you aren’t getting all 
the print output you expect 


If you cannot save a trace 


to the disk 


If you have found a 


problem with the Sniffer 


software 


If your Sniffer hardware is 
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malfunctioning 


Check that you have selected LPT1 or COM1 (as 
appropriate) rather than file for the printer destination. 


Check the From frame and To frame options in the print 
menu. 


Do you have Frame nnn selected instead of First frame or 
Last frame? 


Check the display filters; they affect what is printed. 
Remember that to print the entire detail report you must 
select all protocol levels and turn off highest level only. 


Check the full pathname of the file being created. Is it the 
right drive letter? Do the intermediate subdirectories exist? 


Make sure the hard disk or floppy disk has sufficient space 
for the file. The DOS command cuxpsk can be used for this 
purpose. 

Try to recreate the problem after saving a trace file 
(perhaps filtered) and the setups to a floppy diskette. Then: 
e Start the Sniffer. 

@ Load the trace file. 

@ Load the setups. 


e Recreate the problem. 


If it is a display error, “print” the relevant part of the 
display to a diskette file. 


If you can reconstruct the problem in this fashion, please send the 
diskette to the Network General Corporation Customer Service 
Department. 


Be sure to include your system serial number and the software 
version number (displayed in the initialization screen.) 


See your warranty for more information, and contact the 
Network General Corporation Customer Service Department 
for information about obtaining repairs. 
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Index 


10BASE5 179 
address format 182 
1BASE5 179 
802.3 
address format 182 
IEEE standard 179 
80286-12 processor 39 
> 
count overflow symbol 74 
A/B PRT switch 40 
absolute time 108 
acknowledgment 
example 14 
TCP 21 
Telnet 21 
active window 115 
zoom 119 
adapter card 
Ethernet 40 
adapter plate 
Ethernet connector 40 
lockpost to screws 42 
address 
capitalization 36 
capture filter 3, 16, 57 
capture vs. display filter 37 
destination 15, 35 
DLC 16 
embedded 160 
filler 98 
format 16, 182, 185 
generated frame 88, 89 
higher-level formats 135, 142 
length in display 21 
level 97 
multicast 59 
order in which transmitted 185 
saved setup 132 
source 15, 35 
station 88, 134, 182 
symbolic equivalent 2, 16, 134 
type 99, 134, 138, 141 
unrecognized 81 
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address format 
DECNET address 135, 142 
DLC 135, 142 
DRP address 135 
IP 135, 142 
XNS 135, 142 
address level 16, 35 
blank names limit in name table 134 
effect on displayed names 100 
effect on name table 135 
filter 97, 99, 100 
number of blank names limit 82, 105 
addrtype 
names table 140 
align/CRC errors 
total count 87 
alignment error 
detail view 112 
filter 63, 98 
flag 107 
total count 80, 87 
alphabetization 
names table 142 
ANSI/IEEE 802.3 
Ethernet standard 179 
any station 
station address filter 59, 98 
arrow keys 
to scroll within a window 114 
to traverse menu 49, 50 
ASCII 
hexadecimal view 113 
ASCII characters 
menu option 113 
AUTOEXEC.BAT, file 2, 144, 153 
backbone 
network station 33 
backoff algorithm 181 
backup 
capture files 46 
DOS command 46 
Sniffer software 46 
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bad alignment 

detail view 112 

filler 63, 98 

flag 107 

total count 80 
bad CRC frames 

filler 63 

total count 80 
bandwidth 

network 31 

network utilization estimate 109 
bar graph 

traffic density 79 
baseband 179 
bits per second 

propagation speed 179 
BNC connector 

network transceiver 43, 181 
brightness control 40 
broadband 181 
broadcast 

station address 134 

station address filter 58, 98 
buffer 

chime signal events 81 

full 5, 68 

percentage of space occupied 80 

stopping capture 68 

storage space 82 
build new Sniffer 

custom PI 172 
bus 

network connection 43 
bytes 

captured frame size 73 

cumulative 33, 109 

number in frame 109 
cable 

Ethernet 2, 41, 180 

length 41 

thin Ethernet 180 
cable tester 

automatic 69 

fault diagnosis 93 

menu option 51, 90 
calling conventions 

protocol interpreter 156 
capitalization 

mail address 36 
capture 

address 16 

CAPTURE directory 144 

continuous 68 

contrasted with display 55 


counters 15 
elapsed time 74 
files on demo disk 37 
filter 3, 16, 56, 57 
filter DLC vs. higher-level address 37 
highspeed, menu option 87 
live vs. playback 56 
menu option 51, 68, 69, 70 
meters 15 
new, function key 86 
options during 83 
options, function key 86 
partial 72 
pause during 85 
playback 9, 70 
preparations 52, 55 
procedure 56 
resume 86 
saved setup 132 
stop, function key 65, 86 
stopping criteria 67 
submenu 68 
capture buffer 
capacity 5 
chime signal events 81 
display 6 
format of saved data files 149 
full 5, 68 
load with file of saved frames 129 
not in saved setup 132 
play back file of saved frames 9, 71 
position of trigger 67 
print display 5, 124 
range of frames printed 125 
save to file 5, 6, 86, 130, 145 
storage space 82 
capture filters 
menu option 51, 57, 60 
CAPTURING (label on capture screen) 67 
carrier sense 181 
CGA standard 44 
change path 146 
character 
translation in hex view 113 
Cheapernet 
cable 180 
jumper on Sniffer’s adapter card 181 
propagation speed 92 
check marks 
menu 52 
chime 
during capture 81 
clear 
name table 139 
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clear screen 

function key 83, 86 
clicks 

during capture 72 
collision 

detection 181 

effect on cable test 93 

fragment 181 
collision fragment 

detail view 112 

filler 63, 98 

flag 107 

total count 80 
color monitor 2, 44 

menu option 45, 49 
COM1 126 
COMMAND.COM file 144 


compiler 

protocol interpreter 177 
connect 

Sniffer to network 40 
connector 


Ethernet 2 
Ethernet transceiver 43 
network 41 
continuous capture 68 
contrast control 40 
count 
bytes 4 
frames 4, 15 
kilobytes 4 
tabulation by sender and addressee 15 
count, traffic 
overflow symbol, > 74 
tabulation by sender 74, 76 
tabulation by sender and addressee 74, 75 
CRC error 
detail view 112 
filter 63, 98 
flag 107 
total count 80, 87 
CSMA/CD 181 
cumulative bytes 38, 109 
current directory 145, 147 
custom interpreter 8 
data 
generated frame content 88 
menu option 89 
data display 
function key 86 
data format 
Ethernet vs. TEER 802.3 183 
saved data files 149 
data link control 
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see DLC 16 
data rate 4 
data structure 

protocol interpreter 158 
DB-15 connector 41, 180 
DB-9 connector 2 
debugging messages 

protocol interpreter 165 
DECNET 

address format 135, 142 
defective frame 

counters 80 

counting priority 81 

filter 63, 98 
delay 

menu option 88 
delta time 108 
demo disk 14 

data 37 
demonstrations 

playback 71 

Sniffer 48 
demultiplexed protocol interpreter 155 
density, traffic 4, 79 

bar graph 79 
description 

field in menu 50 
destination 

address 35 

address, generated frame 88 

electronic mail 36 

higher level 19 
detail view 7, 101 

alignment error 112 

CRC error 112 

fragment 112 

frame error 112 

highlight corresponding hex view 116, 118 

protocol level 110 

synchronization with summary view 8, 159 
diagnosis of cable fault 93 
dictionary of station names 134 
<DIR> in list of saved files 71, 148 
directory 

backup 47 

CAPTURE 144 

conventions 145 

current vs. path 147 

DOS 144 

ENDEMO 37 

ENSNIFF 144 

file selection 71 

help 144, 145 

make new 145 
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path not in saved setup 132 
path to different 146, 148 
saved capture files 37, 145 
structure 144 
to run Sniffer 145, 147 
TOOLS 144 
diskette 
backup 46 
prograin 45 
display 
capture buffer 6 
contrasted with capture 55 
detail view 101, 110 
fillers 96 
form of 6 
hexadecimal view 102, 113 
menu option 52, 95 
options during 119 
preparations 52 
real-time 73 
screen vs. printed 127 
set form of 101 
summary view 101, 102 
display filter 5 
address level 97, 99 
defective frames 98 
menu option 96 
pattern 98 
protocol 98, 100 
save frames 130 
saved setup 132 
station address 98 
display filtern 6 
display options 
function key 119 
distance to cable fault 93 
DLC 
address 16, 35 
address format 135, 142 
address level filter 97 
header, pointer 156 
protocol 16, 19, 37 
protocol level in detail view 111, 112 
DM 
LLC protocol 184 
DNS 
protocol 25, 33 
protocol level in detail view 111 
documentation 39 
domain name service 25, 33 
“don’t check” pattern 66 
DOS 
backup command 46 
directory in which stored 144 


operating system 2 
return to 49 
down arrow 50, 53 
drop cable 180 
DRP 
address format 135 
DSAP 
LLC protocol 184 
EBCDIC 
hexadecimal view 113 
EBCDIC characters 
menu option 113 
edit name table 16, 38, 59, 82, 105, 136, 137 
EGA standard 44 
electronic mail 
forwarding 36 
embedded 
address 160 
interpreter 155 
.ENC, file extension 55, 71, 72, 129, 153 
.END, file extension 38, 81, 140, 153 
end key 114 
ENDEMO, directory 37 
.ENS, file extension 131, 132, 153 
ENSNIFF 
directory 144 
ENSNIFF.EXE file 144, 147 
ENSNIFF.HLP file 153 
ENSTART.BAT file 145 
Enter key 
menu 52 
escape sequence 
transmission from terminal 19 
Ethernet 
adapter card 40 
adapter plate for lockposts 40 
architecture 179 
cable 2 
connection 56 
connector 2 
other systems 181 
propagation speed 92 
role of Sniffer 3 
standard 179 
transceiver 2, 41 
Ethertype 
filter 60 
generated frame 90 
other 60, 101 
traffic generator 89 
vs. IEEE 802.3 183 
example 
new PI 174 
over-eager acknowledgment 14 
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problem with routing 23 
sifting outgoing mail 33 
exit 
menu option 52 
to DOS 49 
to selection menu 52 
external monitor 
menu option 49 
fault, cable 69, 90 
fiber optics 181 
file 
accidental erasure 46 
AUTOEXEC.BAT 144, 153 
COMMAND.COM 144 
demonstration 14 
ENSNIFF.EXE 144 
ENSNIFF.HLP 153 
ENSTART.BAT 145 
HDEMO.END 38 
HOSTS.END 140, 142 
load capture buffer 37 
menu option 52, 129 
name conventions 153 
playback 9, 71 
print to 126 
saved frames 5, 71, 86, 129, 130, 145 
saved setup 131 
STARTUP.END 81, 134, 140, 145, 148, 
153 
STARTUP.ENS 153 
symbolic equivalents 37 
TDEMO.ENC 28, 33, 37 
filter 
address-level 97, 99, 100 
capture 3, 56, 57, 71 
criteria for capture 57 
criteria for display 97 
defective frames 63 
display 5, 6, 96 
display, procedure to set 99 
pattern 3, 61, 98 
protocol 3, 98, 100 
save frames 130 
saved setup 132 
station address 3, 57, 98 
FIPS 
Ethernet standard 179 
flag 
alignment error 107 
CRC error 107 
flags option 107, 161 
fragment 107 
mark 107, 108, 109, 119 
trigger frame 67 
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floppy disk 
drive 40 
format 
address 16 
of saved capture files 149 
Pl routines 166 
forwarding 
electronic mail 36 
frame 20 
fragment, collision 63 
detail view 112 
filter 63, 98 
flag 107 
total count 80 
frame 
capture 56 
check sequence 183 
counting defects priority 81 
data field 182 
data format 183 
defective 63 
defective frames reported in detail view 
112 
defects flagged in summary view 107 
fillered out of display 121 
format 182 
forwarding 20 
ID number 31 
interpreter 8 
jump to mark 120, 124 
jump to number 119, 121 
jump to trigger 120, 124 
number, pointer 156 
numbering 115 
partial capture 72 
print report 124 
recorded by Sniffer 3 
scroll to next or previous 120 
search pattern 120, 123 
sequence number 90 
size 57 
traffic generator 89 
trigger 6 
frames 
menu option 89 
frames accepted 
total count 80 
frames per second 
traffic units 79 
frames seen 
total count 87 
FRMR 
LLC protocol 184 
function keys 53 
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capture options 86 
clear screen 83, 86 
display options 119 
display phase 119 
help 86, 119 
menus 86, 119 
new capture 86, 120 
next frame 120 
pause 85 
previous frame 120 
resume 86 
scale down 78, 84 
scale up 83 
select display 78, 83 
set mark 119 
stop capture 86 
view earlier 78, 84 
view later 78, 85 
zoom 119 
gateway 20 
generator 
traffic 9, 88 
good frame 
filter 63, 98 
total count 80 
ground 
network 180 
hard disk 40 
organization of directories 144 
park heads 49 
hardware 39 
HDEMO.END, file 38 
help 
directory 144, 145 
function key 86, 119 
key 50 
on-line 53 
hex view 
character translation 113 
hexadecimal 
highlight corresponding detail view 116, 
118 
station address 82 
view 7, 102, 113 
higher-level 
address 16, 35, 97 
address formats 135, 142 
destination 19 
protocol 7, 155 
source 19 
highest-level-only option 
detail view LL0 
print vs. screen 127 
summary view 105 


highlight 
active window 115 
hex corresponding to detail interpretation 
116, 118, 159 
menu selection 50 
highspeed capture 
menu option 87 
home key 114 
HOSTS.END, file 140, 142 
I 
LLC frame type 184 
ICMP redirect 29 
time-to-live 30 
ID number 
frame 31 
IEEE 802.3 
address format 182 
data format 183 
Ethernet standard 179 
vs. Ethertype 183 
impedance 
network cable 180 
individual counts 4 
menu option 74, 76 
interpretation 
frame 8 
interpreter 
custom 8 
protocol 155 
IP 
address 35 
address format 135, 142 
Ethertype 63 
protocol 14 
protocol level in detail view 111 
sample file of hust names 142 
ISO 
Ethernet standard 179 
jabber detection 
transceiver 182 
jamming signal 181 
jump 
to frame number 119, 121 
to mark 120, 124 
to menu item 50, 53, 130 
to trigger frame 120, 124 
jumper 
thick vs. thin Ethernet 181 
keyboard, Sniffer 40 
kilobytes accepted 
total count 80 
kilobytes per second 
propagation 92 
traffic units 79 
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Kodak Datashow 
LCD display 45 
LCD projector 
display 45 
menu option 45, 49 
leaf, movement towards 51 
left arrow 51 
length 
address field 21 
cable segment 180 
generated frame 88 
license agreement 39 
linear bar scale 
menu option 79 
live capture 70 
resuming 72 
vs. playback 56 
LLC 
frame types 184 
header format 183 
header, pointer 156 
protocol 183 
load 
file of saved frames 37, 129, 132 
saved setup 132 
lockpost 
adapter plate 40 
cable connectors 42, 180 
logarithmic bar scale 
menu option 79 
logical link control 183 
look for names 136, 139 
lost frames 
total count 80 
LPT1 126 
mail 
example 33 
main menu 45 
figure 50 
options 51 
make directory 145 
manage names 
menu 137 
menu option 82, 105 
name table 134 
Manchester encoding 182 
manufacturer code 
address format 185 
mark 
flag 107, 108, 109, 119 
jump to 120, 124 
MAU 
media access unit 180 
media access unit 180 
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memory 
Sniffer 40 
menu 
check marks 52 
command to restart 49 
Inter key 52 
function key during display 119 
function key during pause 86 
jump to item 130 
main 45 
overview 2 
radio controls 53 
scrolling 50 
selection at startup 48 
space bar 52 
tree structure 50 
MENU.BAT file 144 
MENUX.EXE file 144 
meter 
data flow 15 
traffic density 4, 15 
MICOM-Interlan transceiver 43 
Microsoft C compiler 177 
misaligned 
filter 63 
total count 80 
monitor 
brightness control 40 
built-in 2 
color 2, 44 
contrast control 40 
LCD 45 
menu option 49 
monochrome 40 
MS DOS 2, 39, 47 
multicast address 59 
multiple levels 
summary view 105 
N-connector 
network transceiver 43 
name 
DNS protocol 25 
edit name table 105 
information request 24 
length 21 
symbolic 2, 159, 160 
symbolic equivalents resolved from external 
file 37 
width 106 
name service 33 
name table 
additions during capture 134 
additions during display 135 
alphabetization 143 
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blank name limit per address level 82, 105, 
134 
clear 139 
directory 148 
edit 16, 38, 59, 82, 136, 137 
effect of address level 135 
initialization 81, 134 
itemization 142 
look for names 136 
not in saved setup 132 
resolve from external file 136, 140 
save 59, 136, 139, 140 
symbolic equivalents deduced from network 
messages 139 
symbolic equivalents for addresses 16, 134 
symbolic equivalents resolved from external 
file 140 
transmitted within captured frames 136 
working table vs. startup file 136 
NETBIOS 
SAP 184 
symbolic equivalent 136 
network 
address format 185 
bandwidth 31 
capture from 70, 72 
connector 40, 41, 43 
network utilization 31, 109 
bar graph 79 
window in which computed 109 
new capture 
function key 69, 86, 120 
new directory 145 
new station 81 
edit station names 138 
station address filter 59, 98 
next frame 
function key 120 
“No frames selected for display” 99 
non-broadcast 
station address filter 58, 98 
not equal, pattern match 61 
Novell 
symbolic equivalent 136 
NR 
LLC receive sequence number 184 
NS 
LLC send sequence number 184 
numbering of frames 115 
offset 
hexadecimal view 113 
pattern 61, 62, 64 
pattern search 118 
trigger pattern 66 


operating system 2 
options 

saved in setup file 52 
order of transmission 

station address 185 
other Ethertype 

filter 60, 101 
other SAP 

filter 60, 101 
packing list 39 
page up/down keys 114 
pair counts 4 

menu option 74, 75 
pairwise tabulation of traffic 15 
panels of main menu 50 
park hard disk heads 49 
partial capture 72 
path 

different directory 146 

not in saved setup 132 
pattern 

capture filter 3, 61 

display filter 6 

filter 98 

offset 61, 62, 64, 118, 123 

saved setup 63, 132 

search for frame 120, 123 

trigger 6, 64 
pause 

function key 85 

options during 86 
PDS 

Ethernet system 181 
percentage utilization 32 
PI, see protocol interpreter 155 
PIF routines 166, 167 
playback 9, 14, 70 

files on demo disk 37 

selecting file 71 

uses 9 

vs. live capture 56 
plug 

power supply 40 
power 

cord 40 

dual voltage 40 

switch 40 
precautions 

software backup 46 
previous frame 

function key 120 
print 

capture buffer 5, 124, 127 

range of frames 125 


21 The Sniffer: Operation and Reference Manual 


vs. screen display 127 
printer port 126 
.PRN, file extension 126, 153 
processor 
Intel 80286-12 39 
propagation speed 179 
cable test 92 
protocol 
address level 97 
capture filter 3, 60 
DLC 16, 19, 37 
DNS 25, 33 
filler 18, 98, 100 
higher-level 135, 155 
level in detail view 7, 110 
level in print vs. screen 127 
level in summary view 105 
saved setup 61 
TCP/IP 14 
Telnet 14, 18 
protocol interpreter 8, 16, 155 
adding symbolic names 159 
address format 135, 142 
build new Sniffer 172 
calling conventions 156 
compiler 177 
custom 155 
data structure 158 
debugging messages 165 
demultiplexed vs. embedded 155 
existing called by custom PI 161 
formatting 166 
formatting utilities 166, 167 
inter-frame dependencies 163 
memory model 176 
output 158 
registering 157 
return value 156 
type 157 
PUP Ethertype 183 
radio controls 
menu 53 
real-time display 4, 73 
reflectometer 69, 90 
registration 
protocol interpreter 157 
REJ 
LLC reject 184 
relative time 18, 108 
repeater 
network cable 180 
network transceiver 438 
resolve names 37, 136, 140, 141 
RESTORE, DOS command 47 
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resume 
function key 86 
return to DOS 
menu option 49 
return vajue 
protocol interpreter 156 
reverse direction 
station address filter 58, 98 
RGBI video 2, 45 
right arrow 18, 51 
RNR 
LLC receive not ready 184 
root, movement towards 51 


routing 

error 29 

example 23 

table 29 
RR 

LLC receive ready 184 
runt 181 
SABME 

LLC protocol 184 
SAP 


codes in LLC protocol 184 
filter 60 
other 60, 101 
save 
capture buffer 6, 86 
format of captured data files 149 
frames in capture buffer 130 
name table 59, 82, 105 
names 136, 139, 140, 141, 143 
setup 8, 61, 63, 131 
saved frames 
load capture buffer 5 
playback 71 
saved setup 
options included 132 
scale 
linear vs. logarithmic 79 
scale down 
function key 78, 84 
scale up 
function key 78, 83 
schematic view of Sniffer 9 
screw posts 
cable connectors 42 
scroll 
horizontal 18 
menu 50 
synchronization of hex and detail views 
116 
to menu item 53 
to next or previous frame 120 
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view of frame display 7 
window 114 
SDEMO.ENC, file 14 
search 
pattern 120, 123 
text 120, 122 
search for pattern 
saved setup 132 
search, pattern 
offset 118 
select display 
function key 78, 83 
selection menu 48 
sequence number 
generated frame 90 
serial number 
Sniffer 39 
serial port 126 
SET ENNAMES command 148 
set mark 
function key 119 
setup 
customized startup 133 
file 56, 68, 131 
first-time precautions 46 
load previously saved 132 
options saved 132 
save 8, 52, 61, 63 
values saved 131 
shutdown 49 
signal quality error 
transceiver 182 
size 
generated frame, menu option 88 
number of bytes in frame 109 
skylines 5 
active function keys 78 
menu option 74, 77 
slots 
adapter card 41 
SMB 
in trigger pattern 65 
SNA 
SAP 184 
Sniffer 
build new, with custom PI 172 
demonstrations 48 
description 1 
documentation 39 
hardware 39 
menu conventions 52 
restart after exit to DOS 49 
role on Ethernet 3 
schematic view 9 


software 45 
start 45, 48 
symbolic name 134 
software, Sniffer 45 
sound effects during capture 
chime 81 
clicks 72 
source 
address 35 
higher level 19 
space bar 
menu 52 
speed 
propagation 92 
transmission 179 
SQE 
transceiver 182 
SSAP 
LLC protocol 184 
star topology 181 
StarLAN 179 
start 
Sniffer 48 
TeleSniffer 48 
START.END 134 
startup setup 
customized 133 
STARTUP.END file 81, 134, 136, 140, 145, 
148, 153 
alphabetization 143 
STARTUP.ENS file 153 
station address 134 
2-byte 182 
6-byte 182 
filler 57, 98 
format 185 
saved setup 132 
symbolic equivalent 2, 134 
traffic generator 88 
stop capture 
chime 81 
function key 86 
trigger menu 65 
stub 
null 162 
protocol interpreter 155 
subdirectory 
file selection 71 
summary view 6, 17, 101, 102 
address level 100 
fragment 107 
name width 106 
protocol level 105 
synchronization with detail view 8, 159 
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two-station format 18, 21, 103 
symbolic equivalent 
address 16 
display by custom PI 160 
edit 136, 138 
editing 16 
look for 136 
NETBIOS 136 
Novell 136 
station address 2 
symbolic name 
equivalent to station address 134, 141 
width 106 
system shutdown 49 
T, trigger frame flag 67 
Tab key 7, 115, 118, 119 
‘TCP protocol 
acknowledgment 21 
TCP/IP 
protocol 14 
sainple file of host names 142 
TDEMO.ENC, file 14, 23, 33, 37 
TeleSniffer 
menu option 48 
operation and reference manual 39 
start 48 
Telnet 
acknowledgment 21 
protocol 14, 18 
terminal 
transmission from 14, 18 
TEST 
LLC protocol 184 
text 
search 120, 122 
thin Ethernet 
cable 180 
propagation speed 92 
This Sniffer, symbolic name 134 
time 
absolute 108 
delta 108 
display in summary view 108 
elapsed during capture 74 
network utilization window size 109 
relative 18, 108 
time-domain reflectometer 69, 90 
time-to-live 
ICMP redirect 30 
IP parameter 28 
prudent value 31 
To <all stations > 
menu option 88 
token ring 
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topology contrasted to Ethernet 179 
TOOLS directory 144 
topology 
network 179 
Toshiba America, Inc. 39 
traffic 
audible indication 72 
count overflow symbol, > 74 
counters 74 
density 79 
generator 9 
representation by skylines graphs 5 
skylines graph 77 
tabulation by sender and addressee 15 
tabulation by source 4 
tabulation by source and destination 4 
units to calculate 79 
traffic density bar 74 
traffic generator 88 
menu option 51 
sequence number 90 
transceiver 2 
collision detection 182 
Ethernet 41, 180 
installation 43 
jabber detection 182 
transmission order 
address 185 
transmission rate 179 
tree-structured menu 49 
trigger 5, 56 
chime 81 
event 5 
flag 107 
half-byte character pattern 65 
menu option 51, 64 
offset to pattern 66 
pattern 6, 64 
percentage of data in buffer 67 
playback 71 
procedure to set 64 
role of detector 5 
saved setup 132 
trigger frame 6 
flag 67 
position in capture buffer 67 
TRIGGERED (label on capture screen) 67 
truncation of frames during capture 72 
twisted pair 181 
two viewports 8, 22 
menu option 116 
two-station format 7, 18, 21, 103 
selection of stations 104 


type 
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protocol interpreter 157 XX, code for “don’t check” 66 
type of address 99, 138 zoom 
UA active window 119 
LLC protocol 184 function key 118, 119 
UI zoomed view of active window 7 


LLC protocol 184 
unequal, pattern match 61 
unnumbered format 
LLC protocol 184 
unpacking 39 
up arrow 50, 53 
US Defense Communication Agency 183 
utilization 
bar graph 79 
network 31 
vampire tap 
network transceiver 43 
version number, in saved data files 150 
view 
alternatives in display of data 5 
detail 7, 101, 110 
difference between screen and printer 127 
hexadecimal 7, 102, 113 
multiple windows 115 
summary 6, 17, 101, 102 
view earlier 
function key 78, 84 
view later 
function key 78, 85 
viewport 
two 8, 22, 116 
voltage 
power supply 40 
warranty registration 39 
width 
symbolic name 106 
window 
active 115 
display 7, 115 
multiple views 115 
numbering frames 115 
scrolling 114, 116 
specify size for network utilization 109 
two viewports 116 
using during display 114 
zoom in active window 118, 119 
Xerox 
Ethertypes 183 
XID 
LLC protocol 184 
XNS 
address format 135, 142 
in trigger pattern 65 
protocol level 97 
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